Cet article fait suite au premier faisant office d’introduction à la méthodologie BDD : Behavior Driven Development. Il traitera notamment du langage Gherkin, de son utilité et de sa syntaxe.

Comme rappelé dans l’introduction, afin que tous nos contributeurs se comprennent, il est important qu’ils parlent le même langage. Nous allons donc leur faire écrire des scénarios afin d’enrichir les règles métiers ainsi que user stories.

Un langage commun : Gherkin

Gherkin (concombre en anglais) n’est pas un langage de programmation, mais un langage naturel. Il est facile de compréhension, d’utilisation et permet d’expliquer le déroulement d’une fonctionnalité ou d’une application sans rentrer dans les détails.

Gherkin existe dans plus de 60 langues dont l’anglais et le français. Il peut être lu et compris par n’importe qui, donc par l’ensemble de nos contributeurs projet.

Ecrire les scénarios

Scénario (Scenario)

Un scénario comporte un titre et des instructions :

1. Etant donné (Given) : je raconte le contexte, la situation initiale, l’écran sur lequel je me trouve…
2. Quand (When) : je parle de l’action utilisateur ou système (un clic, un changement de valeur…)
3. Alors (Then) : qu’est-ce que j’ai en retour ? comment le système a été modifié ?

Scénario: Servir un café court sans sucre quand je fais l'appoint
Etant donné que j'ai inséré 40 centimes d'euros
Quand je demande un "café court sans sucre"
Alors la machine me remplit un gobelet de "café court sans sucre"

Il est aussi possible de compléter les instructions par d’autres commençant avec les mots Et (And) et Ou (Or) :

Scénario: Servir quand je fais l'appoint en deux fois
Etant donné que j'ai inséré 30 centimes d'euros
Et que j'ai inséré 10 centimes d'euros
Quand je demande un "café court sans sucre"
Alors la machine me remplit un gobelet de "café court sans sucre"
Et la machine ne me rend pas de monnaie

Ce qui revient à écrire :

Scénario: Servir quand je fais l'appoint en deux fois
Etant donné que j'ai inséré 30 centimes d'euros
Etant donné que j'ai inséré 10 centimes d'euros
Quand je demande un "café court sans sucre"
Alors la machine me remplit un gobelet de "café court sans sucre"
Et la machine ne me rend pas de monnaie

Comme vu dans notre exemple, il est possible de traiter avec des informations simples comme des nombres ou des chaînes de caractères (à l’aide des guillemets). Nous y reviendrons un peu plus tard, notamment dans la mise en application de ces scénarios.

Il est également possible de traiter des informations plus complexes à l’aide de tableaux :

Scénario: Refuser l'entrée si je suis mineur
Etant donné que l'utilisateur suivant
   | nom    | prenom | age |
   | Dupont | Jean   | 17  |
Quand je demande si je peux rentrer dans le casino
Alors le contrôleur m'indique "Vous n'êtes pas autorisé à entrer"

Ou encore :

Scénario: Connexion avec un mot de passe incorrect
Etant donné que l'utilisateur suivant
   | nom    | prenom    | email               | motDePasse |
   | Dupont | Jean      | jdupont@test.com    | azerty123  |
Quand je tente de me connecter avec les coordonnées
   | email            | motDePasse |
   | jdupont@test.com | toto26     |
Alors un un message m'indique "Le nom utilisateur ou le mot de passe est incorrect"

Plan de scénario (Scenario Outline)

Les plans de scénario sont utiles si l’on souhaite tester un même scénario avec plusieurs jeux de données.
Prenons ces 2 scénarios strictement identiques, avec des jeux de données différents :

Scénario: Servir un café court sans sucre en deux fois (30 cts puis 10 cts)
Etant donné que j'ai inséré 30 centimes d'euros
Et que j'ai inséré 10 centimes d'euros
Quand je demande un "café court sans sucre"
Alors la machine me remplit un gobelet de "café court sans sucre"
Et la machine ne me rend pas de monnaie

Scénario: Servir un café court avec sucre en deux fois (20 cts deux fois)
Etant donné que j'ai inséré 20 centimes d'euros
Et que j'ai inséré 20 centimes d'euros
Quand je demande un "café court avec sucre"
Alors la machine me remplit un gobelet de "café court avec sucre"
Et la machine ne me rend pas de monnaie

Ils peuvent être simplifiés comme ceci :

Plan de Scénario: Servir un café court en deux fois
Etant donné que j'ai inséré <monnaie1> centimes d'euros
Et que j'ai inséré <monnaie2> centimes d'euros
Quand je demande un "<nom>"
Alors la machine me remplit un gobelet de "<nom>"
Et la machine ne me rend pas de monnaie

Exemples:
  | monnaie1 | monnaie2 | nom                   |
  | 30       | 10       | café court avec sucre |
  | 20       | 20       | café court sans sucre |

Fonctionnalité (Feature)

Une fonctionnalité est un groupement de plusieurs scénarios et/ou plans de scénario.
Chaque scénario/plan de scénario doit être intégré dans une fonctionnalité.
Une fonctionnalité représente un fichier qui contient un ou plusieurs scénarios/plans de scénario.

Voici un exemple d’une fonctionnalité contenant 3 scénarios :

Fonctionnalité: Servir un café
   En tant qu'utilisateur
   Je veux consommer un café
   dont le prix fixe est de 40 centimes

   Scénario: Servir un café court sans sucre quand je fais l'appoint
      Etant donné que j'ai inséré 40 centimes d'euros
      Quand je demande un "café court sans sucre"
      Alors la machine me remplit un gobelet de "café court sans sucre"

   Scénario: Servir un café court sans sucre quand je donne trop de monnaie
      Etant donné que j'ai inséré 1 euro
      Quand je demande un "café court sans sucre"
      Alors la machine me remplit un gobelet de "café court sans sucre"
      Et la machine me rend 60 centimes d'euros

   Scénario: Pas assez de monnaie
      Etant donné que j'ai inséré 30 centimes d'euros
      Quand je demande un "café court sans sucre"
      Alors la machine me demande de rajouter 10 centimes d'euros

Contexte (Background)

Si vos scénarios ont besoin d’un ou plusieurs pré-requis avant de pouvoir être vrais (par exemple : il faut avoir crée un compte, il faut être connecté, il faut avoir passé l’étape 1 etc.), la notion de contexte peut être  intéressante.
Le contexte permet de jouer une ou plusieurs instructions de type Etant donné avant chaque scénario.

Fonctionnalité: Servir un café
   En tant qu'utilisateur
   Je veux consommer un café
   dont le prix fixe est de 40 centimes

   Contexte:
      Etant donné que j'ai inséré 40 centimes d'euros

   Scénario: Servir un café court sans sucre  
      Quand je demande un "café court sans sucre"
      Alors la machine me remplit un gobelet de "café court sans sucre"

   Scénario: Servir un café court avec sucre quand je fais l'appoint
      Quand je demande un "café court avec sucre"
      Alors la machine me remplit un gobelet de "café court avec sucre"

   Scénario: Servir un café court avec sucre quand je donne trop de monnaie
      Etant donné que j'ai inséré 10 centimes d'euros
      Quand je demande un "café court avec sucre"
      Alors la machine me remplit un gobelet de "café court sans sucre"
      Et la machine me rend 10 centimes d'euros

La ligne Etant donné située dans le bloc Contexte sera joué systématiquement avant chaque scénario.

Où écrire ces scénarios ?

Un simple éditeur de texte (même un bloc-note) peut suffire pour écrire des scénarios !

Toutefois, nous allons nous forcer à respecter 3 conventions simples :

1. Les scénarios et plans de scénario seront regroupés par fonctionnalité
2. Une fonctionnalité = Un fichier
3. Les fichiers porteront l’extension .feature

Il existe à la fois des outils ou des extensions permettant de rédiger des scénarios avec une coloration syntaxique. Ces outils peuvent être utilisés et projettés sur un écran pendant une atelier par exemple :

• TidyGherkin : une extension pour Chrome et Edge
• Une extension pour Visual Studio Code
• Une extension pour Sublime Text

Enfin d’autres outils mais dont nous parlerons un peu plus tard : Cucumber, SpecFlow, Behat etc…

Vous pourrez retrouver plus d’informations et de la documentation sur Gherkin ici :

• Writing Features with Gherkin (Behat)
• Syntaxe du langage Gherkin en français (Behat)

Vous voici en possession des principales règles et caractéristiques du langage Gherkin.
Comme vous le voyez, le langage se veut simple et business-readable.
Il n’est pas complexe et demande simplement un peu de rigueur.

Une fois les scénarios rédigés par nos 3 amigos, à savoir dev-testeur-PO, ces derniers peuvent être implémentés au niveau de notre code applicatif.
Le prochain article traite justement de ce point.