Gherkin

Référence : * https://wefiit.com/rediger-en-gherkin/ * https://www.artza-technologies.com/blog/langage-gherkin * https://blog.myagilepartner.fr/index.php/2020/05/25/gherkin-given-when-then/ * https://essnature.com/fr/quest-ce-que-gherkin-comment-%C3%A9crire-des-tests-gherkin/

Origine : BDD

C’est à l’origine un outil destiné aux développeurs pour permettre une approche structurée de l’écriture des tests comportementaux. Nous pouvons ensuite nous baser dessus pour piloter les développements (i.e. “BDD”, ou “Behavior Driven Development).

Coder un “test comportemental”, signifie de coder un test reproduisant la façon dont les utilisateurs interagissent avec l’application, sans avoir à rentrer dans les détails de leur mise en œuvre (i.e. on n’a pas besoin de connaître les aspects techniques du service).

Gherkin est le format des spécification de Cucumber, dont l’intérêt est d’être compréhensible par toutes les parties prenantes du produit. Par conséquent, il peut être utilisé pour communiquer le comportement du service entre le PO, les développeurs, et la Q.A.

Le fonctionnement : un langage commun

Pour être accessible à tous, très simple : Gherkin fournit un langage commun.

Attend voir … “très simple”?

Oui, bon, le format est très simple. Il s’agit de décrire le service sous la forme d’une phrase du style :

“Étant donné que , quand , alors “.

Ainsi, on retrouve : * l’utilisateur et son rôle (enfin, on peut le préciser), * les conditions de départ (donc les paramètres d’entrée), * l’action de l’utilisateur (ce qu’il va faire avec le service), et enfin, * le résultat que l’utilisateur s’attend à observer, après son action.

Cette formulation permet de se centrer sur l’utilisateur, plutôt que sur les aspects techniques, ce qui est cool pour le PO, quand il rédige ses User Stories. Et pourtant, la Q.A. pourra décrire ses scénarii de test sur cette base, et les développeurs, automatiser leurs tests.

Autre chose d’intéressant, avec Gherkin, c’est que ce langage est compris par des outils comme Cucumber (capable de lire et exécuter le test correspondant au scénario décrit), ce qui implique donc l’automatisation directement à partir des tests écrit par le PO (si c’est pas magnifique … enfin bon, même sans ça, c’est déjà pas mal, non ?).

Gherkin se base ainsi sur un ensemble de mots clés, tels que : * “Fonctionnalité” : une description textuelle de la fonctionnalité qu’on s’apprête à tester; * contexte : permet de décrire cette fonctionnalité; * “Scénario” : une fonctionnalité peut être testée via plusieurs scénarii (i.e. les différents cas d’usage de la fonctionnalité); * “Étant donné” : introduit le contexte spécifique à un scénario donné; * “Quand” ou “Lorsque” : introduit l’action de l’utilisateur; * “Alors” : introduit les conséquences de l’action utilisateur; * “et” : permet de séparer les différentes conditions d’entrée, ou différentes étapes de l’action, ou différentes conséquences; * “mais” : fait l’inverse de “et” (i.e. soustrait une condition / étape / conséquence par rapport au contexte).

Les règles d’or

Ce genre d’outil fournit un cadre, mais il est toujours possible d’en sortir. Alors pour le renforcer, quelques règles doivent toujours être ajoutées : 1. une User Story doit correspondre à une fonctionnalité; 2. un scénario doit correspondre à un - et un seul - comportement, un cas d’usage, de la fonctionnalité; 3. la description (contexte, conditions, etc.) doit être claire et compréhensible par n’importe quelle partie prenante.