Tests fonctionnels du site

OK, donc il faut essayer de mesurer la qualité de la DSL de lettuce / cumcumber.

Là je m'efface car je ne la connais pas assez. J'apprécie l'approche geb car justement la DSL est fait pour des devs tout en restant compréhensible par des humains dans des cas simples.

La syntaxe de sélecteurs jquery est quasiment comprise par tous les développeurs aujourd'hui. C'est presque devenu un standard de fait . Donc c'est parlant. La syntaxe à base de expect, when, then, and, where permet de structurer le test de façon à ce qu'il se lise comme un test (et ça c'est hyper important et parfois difficile à lire dans les TU : "mais qu'est-ce-qu'il veut faire ???"). "Quand je fais ci, j'attends ça. Je paramètre mon test pour qu'il turne avec X ou Y cas" c'est ça un test. Et la DSL doit mettre ça en avant.

Je vous laisse juger de la DSL de lettuce. Là, je peux plus trop avancer de retour d'expérience, malheureusement.

Quand j'ai relevé l'utilité de ce genre de tests, le but principal était surtout de soulager la QA au maximum. Quand on fait un tour sur le dépot du projet, on constate souvent des indications du genre (dans les issues, comme dans les tests de la PR) :

ou encore

On est sur la même logique avec un outil comme lettuce. Et plutot que ce soit quelqu'un qui lance le site, clique par ci et par là, c'est celui qui fait la QA qui s'en chargerait tout simplement en rédigeant les cas de tests un peu tordu et en laissant faire la machine.

L'avantage ici étant qu'on teste presque tout de manière automatique et que ça reste plus lisible pour quelqu'un qui ne connait pas le python que les fichiers de tests écrit en python.

En gros, ça revient à rédiger un cahier de recette qui sera déroulé automatiquement. L'outil ne fait que tester que ton site affiche ce qu'il doit affiche quand tu appuie sur les bon bouton. En tout cas de ce que j'ai pu voir en le testant, ça me parait tout indiqué.

Après y'a en effet un usage… Au boulot, ça va faire deux ans qu'on est passé sur du Gherkin, mais dans un excès de zèle, on a fait trop de phrases spécifique a une action. Alors, développant une API REST, on aurait du se limiter à ce genre de trucs (c'est d'ailleurs dans les cartons) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Scenario: Foo
  Given I am authenticated as test
  When I prepare a "GET" HTTP request to "/foo"
    And I add a parameter "bar" with a value "baz"
    ...
    And I send the request
  Then the response status code should be 200
    And I should have a json response
    And I should have a key `success[data]`
    ...

Ce qui est tout de même assez clair, ne demande pas beaucoup de contexte à développer, … et reste surtout compréhensible par un péon qui arrive plus tard sur le code (ou pour nous, un dev front qui veut utiliser notre api). C'est en effet le standard introduit par Cucumber (Given, When, Then).

En fait cela soulagerait la QA qui n'aurait plus à se tapper les erreurs 500 mais la QA teste aussi l'UX donc ton scénario elle devra le faire quand même, malheureusement.

Les seules fois ou on aurait besoin de tester l'UX serait en cas de modification de css. Et encore c'est le genre de chose qu'on peut se permettre de découvrir en phase de release (car un problème d'affichage css est vite hotfixé).

c'est le genre de chose qu'on peut se permettre de découvrir en phase de release

Attention à ne pas confondre UX et design. Je ne doute pas une seconde que tu fasses la différence, mais c'est pas clair dans ton message.

L'UX est couverte par ce genre de tests. C'est même leur intérêt premier.

Typiquement : "Je dois pouvoir envoyer mon tutoriel en validation par un simple clic sur la page A" c'est de l'UX, et c'est couvert : le bouton est présent, quand je clique dessus je suis redirigé vers la bonne page et mon tutoriel est passé en attente de validation.

Par contre, le fait que le menu soit à gauche et pas à droite, ça c'est hors scope. On sait que la fonctionnalité est disponible de la façon dont on l'a pensée (donc on est pleinement dans l'UX : c'est le clic sur un bouton qui permet la fonctionnalité) donc on couvre une partie seulement de l'ergonomie (on est agnostique de l'agencement des boutons par exemple). Juste pour clarifier ton propos si tu permets.

L'UX est couverte par ce genre de tests. C'est même leur intérêt premier.

Non. elle ne teste pas la facilité d'accès, la rapidité de réaction etc. Elle teste juste la fonctionnalité et peut être sa fluidité mais pas plus. Tu peux faire ressembler ZDS à blender, ton UX sera pourrie, tous les tests fonctionnels passeront.

Typiquement : "Je dois pouvoir envoyer mon tutoriel en validation par un simple clic sur la page A" c'est de l'UX

typiquement "le bouton se trouve en gros est le premier à être accessible, n'est jamais supperposé à un autre élément d'interface quand on scroll, ne doit pas être caché dans un menu… ça c'est de l'UX qui ne peut être testée fonctionnellement.

Je parle de ce qu'il s'est passé lors de l'élaboration de la ZEP03 là, pas d'hypothèse, de réalité.

Oui, c'est bien ce que j'appelle problème dans le css. Il n'existe pas encore de méthode fiable pour tester automatiquement que le code sera fidèle à la maquette attendue. En fait si, on peut toujours screenshooter un écran automatiquement et comparer le rendu avec une maquette pré-designée (comparaison d'image toussa), mais ça serait un peu overkill.

Comme l'exprimait très justement AlexD à l'époque le front n'est pas que le design et si l'UX s'appuie clairement sur la maquette visuelle, elle ne contient pas que ça.

Ce que tu appelles dse "problèmes de css" sont bien plus que ça. Penses-tu que l'accessibilité aux personnes qui sont obligées d'utiliser un lecteur d'écran ne se règle qu'avec du CSS? Crois-tu que c'est un simple "problème de CSS" que d'avoir ZDS qui fait crasher IE sur Windows Phone? Crois-tu que l'ajout du lien vers les messages privé dans la ZEP03 soit un "problème de CSS"? Pourtant on est en plein dans l'UX. De même, lorsque le validateur valide un tutoriel, dans l'ancien modèle un MP était envoyé un chaque auteur. Fonctionnelement parlant le test aurait dit "trop cool", mais côté UX, ça faisait deux discussions cloisonnées jusqu'à ce que le valido ajoute un participant.

Les tests fonctionnels sont des tests de non régression, soyons honnêtes, ZDS n'est pas développé selon la méthode du TDD. En fait, on n'est même pas dans les clous de n'importe quelle méthode existante. Tant que nos membres s'y retrouvent c'est bien mais il va falloir être honnêtes : nous allons devoir quand même faire des tests de QA chez nous. Ne serait-ce que parce que notre site est responsive et donc doit être testé sur plusieurs plateforme. Une QA c'est long parce que je dois tester sur mon ordi ET sur mon mobile. Un jour peut être même sur tablette.

Penses-tu que l'accessibilité aux personnes qui sont obligées d'utiliser un lecteur d'écran ne se règle qu'avec du CSS?

L'accessibilité est un vaste de domaine. Et oui, les tests fonctionnels (tels que décrit ici) peuvent couvrir une partie d'accessibilité. Vérifier que les balises img ont toujours un attribut alt, verifier que la touche Echap te permet de fermer une modale, vérifier que ta page contient des titres, etc. Tout ceci peut être englobé dans une directive "Je m'assure que ma page est accessible". Il te reste des choses que tu ne pourras pas tester, mais si ça arrive, le problème sera sans doute coté css.

Crois-tu que c'est un simple "problème de CSS" que d'avoir ZDS qui fait crasher IE sur Windows Phone?

Ce problème est couvert par les tests fonctionnels car il te suffit de demander à selenium de démarrer un webdriver windowsphone et de lancer ses tests dessus.

Crois-tu que l'ajout du lien vers les messages privé dans la ZEP03 soit un "problème de CSS"?

Ce cas est lui aussi couvert. Et comme pour tous les tests, il faut avoir écrit quelque part "Je veux que sur ma page d'aide, un lien soit affiché pour contacter l'auteur".

Les tests fonctionnels sont des tests de non régression, soyons honnêtes

Là c'est peut être parce que tu ne les a jamais utilisé comme il faut. L'idée n'est pas de dire qu'on ne fera plus jamais de QA, mais que l'idée de la QA se résumerait à rajouter un cas non testé dans le tableau.

Si je prend le cas de j'ai écris en gherkin :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Fonctionnalité: Inscription
    Pour parvenir à utiliser le site pleinement en tant qu'utilisateur nous devons être inscrit

    Scénario: Accéder à la page d'inscription étant déconnecté
        Je ne suis pas connecté
        Quand je vais sur le lien inversé "register"
        Je vois dans le titre1 "Inscription classique"
        Je vois dans le titre1 "Inscription via reseau sociaux"

    Scénario: Réaliser une ou plusieurs inscription(s)
        Utiliser selenium
        Je ne suis pas connecte
        Je vais sur le lien inversé "register"
        Je remplis le champ "id_email" avec "<email>"
        Je remplis le champ "id_password" avec "<password1>"
        Je remplis le champ "id_password_confirm" avec "<password2>"
        Je remplis le champ "id_username" avec "<username>"
        Clique sur le bouton "input[name=submit]"
        Le résultat de la soumission du formulaire doit etre "<result>"
        Si "<result>" est OK alors j'ai reçu un mail dont l'objet est "Confirmation Inscription"
        Si "<result>" est OK alors j'ai reçu un mail avec dans le message "Merci"
        Si "<result>" est OK alors je ne peux pas encore me connecter avec "<username>" et "<password1>"
        Si "<result>" est OK alors je clique sur le lien d'activation dans le mail
        Si "<result>" est OK alors je peux me connecter avec "<username>" et "<password1>"

    Exemples:
        | email             | password1   | password2   | username | result |
        | user1@gmail.com   | password1   | password1   | user1   | OK      |
        | user2@gmail.com   | password1   | password2   | user2   | KO      |
        | user3@gmail.com   | user3       |  user3      | user3   | KO      |
        | user1@gmail.com   | password1   | password1   | user4   | KO      |

C'est assez simple de lire ce que je teste et ce que je n'ai pas testé. Tout aussi simple de rajouter un nouveau cas de test.

Cependant les test unitaires pures doivent rester. Mais les tests d'intégrations que l'on fait aujourd'hui en python ne sont pas efficaces

@artragis:

Déjà, du calme. Je te trouve bien véhément, surtout quand tu parles de "pas d'hypothèse, mais de réalité". Je sais pas trop comment je dois le percevoir, donc soufflons deux secondes.

il va falloir être honnêtes : nous allons devoir quand même faire des tests de QA chez nous

Bien évidemment. Et personne n'a dit le contraire. Et je pense qu'autant Talus que firm1 (j'imagine ?), moi ou tout autre personne qui emploie cette méthode pourra te dire qu'avoir des tests d'intégration n'empêche pas qu'il y ait une passe de QA manuelle. Les deux sont parfaitement complémentaires (entre autres pour certaines raisons que tu as citées).

L'idée, c'est de pouvoir faire de la QA "le coeur léger". Bien entendu qu'une ZEP qui part en prod va passer par des tests manuels, va être confrontée à des utilisateurs, va passer sur tablette, mobile, etc. Encore heureux…

Simplement, l'énorme avantage de ces tests (outre repérer des régressions) c'est surtout de pouvoir soulager la QA. Et le mot "soulager" est important. La QA ne devrait plus dérouler des scénarios préconçus pour reproduire des bugs. Ce n'est pas intéressant à faire d'une part, c'est rébarbatif et ça ennuie tout le monde. Là, le but du jeu de la QA manuelle devient (grosso modo) : "joue avec l'interface en tant qu'utilisateur et remonte tes attentes/problèmes, la majorité des scénarios et des problèmes bloquants sont déjà couverts".

Quand tu parles d'accessibilité aux lecteurs d'écran c'est le contraire pour moi. Les règles qu'a décrites QuentinC dernièrement sont assez faciles à modéliser à l'aide de ce genre d'outils (les items de navigation sont bien des liens, …). En tout cas bien plus simple que d'installer un lecteur d'écran ou aller demander à un membre qui dispose d'un lecteur d'écran.

Tu t'enflammes pour pas grand chose. Ce que j'appelle ergonomie (et je l'ai précisé dans mon message) n'est pas entièrement couverte par ce genre de tests. L'agencement des éléments, leur affordance, l'organisation d'éléments de formulaire, etc. autant de choses cruciales qui vont manquer.

Par contre oui, on a une garantie partielle que l'interface n'est pas bloquée, que les éléments attendus sont là, même si malheureusement ils ne sont pas placés où on le souhaiterait. Bref, que la fonctionnalité est utilisable. Pas imperfectible, mais décente. Et oui, quand une nouvelle fonctionnalité/page sort, tu auras une passe manuelle très importante à faire dessus. Ça tombe bien, puisque tu auras passé moins de temps à chasser des régressions.

Maintenant, je ne pense pas que ça vaille la peine de s'étriper, je pense que personne n'est assez cinglé pour dire qu'on pourra se passer d'une passe de tests manuels. Faut juste voir la chose suivante : une régression détectée par un test auto, c'est autant de temps gagné en QA (puisque si tu l'avais vu en QA, ça voulait dire re-belotte).

Déjà, du calme. Je te trouve bien véhément, surtout quand tu parles de "pas d'hypothèse, mais de réalité". Je sais pas trop comment je dois le percevoir, donc soufflons deux secondes.

Je ne suis pas véhément, je suis un de ceux qui a poussé l'amélioration des tests unitaires pour ZDS alors tu sais, plus de tests pourquoi pas? surtout si les gens derrière maîtrisent l'outil.

Le truc c'est que je vois firm1 qui dit "ça allégera la QA car ça permettra d'éviter de tester les scénarios". Comme je le disais, cela n'aura pour effet que de tester que la fonctionnalité existe et est opérationnelle. L'UX n'est pas testée. Si lorsque je fais ma QA je vois que sur mobile c'est complexe à utiliser, va quand même falloir que je me tappe tout. La seule différence c'est que les erreurs 500 ne seront pas à tester car le test fonctionnel sera là point.

Quand je dis "la réalité", c'est que personnellement je parle au présent. j'ai vu et j'ai appris de ce que les différents gros développements du site ont manqué. On a déjà pas mal corrigé le tir par rapport à l'instabilité que cela avait causé dans le module de tuto lors de la publication du site. Nous sommes une très bonne équipe et nous apprenons de nos erreurs.

Maintenant quand on présente de manière très incantatoire ce que pourrait nous amener un outil, je me méfie surtout que les plus gros problèmes que nous avons eu se sont situé au niveau… des outils. npm qui plantait, pip qui voulait pas installer lxml, cabal qui mettait des plombes à compiler… Aujourd'hui on nous propose d'ajouter un outil, que finalement peu de personnes n'a utilisé car chacun a utilisé ses propres outils de tests, du selenium de base à cucumber en passant par quelques autres. Alors, oui, je doute.

je doute d'autant plus que la proposition se base sur l'idée que nous sommes sensé faire du TDD mais que l'historique de git nous prouve… le contraire.

Je pense qu'on a pensé que je m'enflammé car l'écrit ne permet pas de transmettre réellement l'état dans lequel on est mais, là je suis calme, j'essaie de voir le pour et le contre. Bon après, je vais aussi avouer que j'ai toujours eu un très mauvais ressenti avec les fuameux outils qui voulaient parler en "langage courant". Encore pire quand on utilise les users story. Les given when then, je suis venu, j'ai vu, j'ai vomis. Il faudrait que je ressorte le cahier fonctionnel d'un de nos projets où d'une fonctionnalité dont on avait une idée très claire malgré sa complexité à implémenter nous avions dû faire une quinzaine d'user story tous trop long à cause des conjonctions et disjonctions. Tout n'est pas fait pour être formulé dans ce formalisme.

Je ne donne que mon avis. J'adore la philosophie ZDS qui prône la démocratie. Si vous mettez en place un outil de test fonctionnel, non seulement je m'y formerai mais en plus je l'utiliserai de manière assidue car je crois en ce projet. Mais pour l'instant, je suis perplexe quant à leur facilité d'utilisation, leur stabilité et le temps (la ressource dont on manque le plus) qu'ils nous demanderont.