14 Octobre 2020
Il n’est plus à prouver qu’en tant que Product Owner, la bonne compréhension des User Stories par l’ensemble des parties prenantes constitue l’un de vos enjeux majeurs.
Et il est certain aussi qu’aujourd’hui vous maîtrisez le concept de « En tant que
Aujourd'hui, nous allons voir ensemble comment utiliser Gherkin, un framework simple pour décrire ce qui doit être construit.
Destiné à l'origine aux développeurs, Gherkin est une approche structurée de l'écriture de tests comportementaux, également appelée Behavior Driven Development (BDD) . Au lieu de tester de petits bouts de code, les tests comportementaux cherchent à suivre le véritable flux de travail de l'utilisateur, comme la connexion ou la demande de remboursement. Cela signifie une concentration sur la façon dont les utilisateurs interagissent avec votre système.
Gherkin est le format des spécifications du Cucumber. C’est un langage spécifique à un domaine, compréhensible par toutes les parties prenantes, créé spécialement pour les descriptions de comportement sans avoir besoin d'entrer dans les détails de la mise en œuvre.
Gherkin a deux objectifs : servir de documentation de votre projet et de squelette de vos tests automatisés. Il est basé sur une grammaire qui existe dans plus de 37 langues. Par conséquent, vous pouvez écrire votre code Gherkin dans plus de 37 langues parlées.
Le besoin de Gherkin peut être facilement expliqué par les images suivantes :
Il s'avère que ce qui ressort de l'écriture de tests comportementaux est identique à l'écriture de User Stories : un aperçu de l'objectif que l'utilisateur souhaite atteindre, des étapes qu'il entreprendra et de la manière dont le produit doit répondre.
Gherkin peut donc être considéré comme étant le framework idéal pour écrire des User Stories car il donne une approche cohérente pour examiner tous les scénarios, apporte la définition de Terminé et fournit des critères d'acceptation précis.
Gherkin est un langage orienté ligne, tout comme YAML et Python. Chaque ligne est appelée step et commence par un mot-clé.
Gherkin utilise un ensemble de mots-clés spéciaux pour donner une structure et une signification aux spécifications exécutables. Et comme mentionné ci-dessus, chaque mot-clé est traduit dans de nombreuses langues parlées ; dans cette référence, nous utiliserons le Français.
Les principaux mots clés utilisés dans Gherkin sont :
Il existe également quelques mots clés secondaires :
Les commentaires ne sont autorisés qu'au début d'une nouvelle ligne, n'importe où dans le fichier d'entités. Ils commencent par zéro ou plusieurs espaces, suivis d'un signe dièse (#) et d'un texte.
Des espaces ou des tabulations peuvent être utilisés pour l'indentation. Le niveau d'indentation recommandé est de deux espaces.
Un document Gherkin a une extension .feature et c’est un simple fichier de test avec une extension sophistiquée. Cucumber lit le document Gherkin et exécute un test pour valider que le logiciel se comporte selon la syntaxe déclaré dans le script Gherkin.
Fonctionnalité :
Le fichier doit avoir l'extension .feature et chaque fichier ne doit avoir qu'une seule fonctionnalité. Le mot-clé de fonctionnalité étant « fonctionnalité: » et doit être suivi par le nom de la fonctionnalité.
Scénario :
Chaque fichier de fonctionnalités peut avoir plusieurs scénarios et chaque scénario commence par « Scénario : » suivi du nom du scénario.
Contexte :
Le mot-clé contexte (background en Anglais) vous aide à ajouter du contexte au scénario. Il peut contenir certaines étapes du scénario, mais la seule différence est qu'il doit être exécuté avant chaque scénario.
Pour chaque User Story, un ensemble de scénarios (de 1 à environ 4 au maximum) décrit le comportement attendu en Gherkin :
Etant donné que ‘contexte initial’
Quand ‘un événement’
Alors ‘un certain résultat’
Un exemple familier pour les chefs de produit :
Fonctionnalité : Connexion utilisateur
En tant qu'utilisateur, je souhaite me connecter pour voir mes campagnes marketing
Scénario: l'utilisateur fournit le nom d'utilisateur et le mot de passe corrects
Étant donné que je suis sur la page de connexion
Lorsque j'entre mon nom d'utilisateur et mon mot de passe correctement
et que je clique sur `` Se connecter ''
Alors je suis redirigé vers le tableau de bord
Scénario: L'utilisateur ne fournit PAS le nom d'utilisateur correct et mot de passe
Étant donné que je suis sur la page de connexion
Lorsque je saisis mon nom d'utilisateur et mon mot de passe de manière incorrecte
et que je clique sur "Connexion"
Alors le message d'erreur "Désolé, nom d'utilisateur ou mot de passe incorrect" s'affiche.
Gherkin suit une syntaxe très spécifique :
Scénario -> Étant donné -> Lorsque -> Alors
Scénarios : toutes les actions qu'un utilisateur pourrait entreprendre (y compris une mauvaise saisie)
Etant donné : définit le contexte. Sur quelle page sommes-nous et dans quel état sommes-nous ? L'utilisateur est-il un administrateur ? Connecté ? A créé une campagne ?
Lorsque : quelles actions l'utilisateur exécute. Quel événement s'est produit ?
Alors : que devrait faire le système en réponse ? Quel est le résultat attendu ?
Fonctionnalité : Avoir un compte bancaire
Afin d'offrir aux utilisateurs la possibilité d'avoir un compte
Etant donné que je suis inscrit
Je dois être capable d'ajouter ou de retirer de l'argent
Scénario : Ajouter de l’argent
Etant donné que je suis un utilisateur connecté
Et que j'ai un compte bancaire
Et que le solde de mon compte est de 10 euros
Lorsque j'ajoute 5 euros sur mon compte
Alors mon solde doit être de 15 euros
Plan du Scénario :
Etant donné que j'ai un compte bancaire
Et que le solde de mon compte est de
Lorsque j'ajoute
Alors mon solde doit être de
Examples :
| soldeInitial | montant | soldeFinal |
|---|---|---|
| 5 | 10 | 15 |
| 20 | 20 | 40 |
| 20 | 7 | 27 |
| 0 | 10 | 10 |
Vous avez certainement remarqué dans ce dernier exemple, l’utilisation d’un tableau d’injection de valeurs de tests, pour que cela reste fonctionnel, il suffit de préciser le terme « Plan du scénario » (ou Outline en anglais). Celui-ci permet donc de tester ce scénario pour les 4 cas de figures présentés.
Ne mentionnez aucun détail technique, comme les colonnes de base de données ou les classes CSS. L'accent doit être mise sur l'utilisateur et ses comportements. Efforcez-vous de garder les détails techniques en dehors de votre code Gherkin, sauf si vous écrivez une API. Même dans ce cas, il ne doit pas y avoir de référence à COMMENT le code doit être écrit.
rambaud
Bonjour, juste pour vous signaler que les balises ne passent pas bien lors de l'explication du "plan de scénario". En effet les différents paramètres sont renseignés en gherkin via les chevrons <paramètre>. On retrouve bien les paramètres dans le code source de la page mais ces balises sont interprétées (sans résultat) comme des balises html. C'est en tout cas l'impression que j'ai
KARIM
le langage Gherkin est très bien expliqué Comment on pourait traduire le langage Gherkin en langage Eggplant
