====== Les bases de la rédaction en Gherkin ======

Issu de la pratique du **Behavior Driven Development (BDD)**, le langage **Gherkin** est très souvent associé aux projets agiles car il permet de décrire de manière cohérente les comportements d'un utilisateur.

Il peut être utilisé par le **Product Owner**, le **QA Agile** et les **développeurs**. Son objectif est de créer une documentation homogène grâce à des règles de rédaction communes.

===== Qu'est-ce que le langage Gherkin ? =====

==== Pourquoi utiliser le langage Gherkin ? ====

L'un des enjeux majeurs d'un projet agile est d'assurer une communication claire et efficace entre le Product Owner, les développeurs et les QA.

Le Gherkin répond à ce besoin en proposant un langage compréhensible par tous les intervenants du projet.

Les discussions sont alors centrées sur les comportements attendus de l'utilisateur plutôt que sur une succession de règles techniques.

==== Utilisation dans une organisation agile ====

Le langage Gherkin est utilisé par :

  * Le Product Owner pour rédiger les User Stories.
  * Le QA Agile pour rédiger les critères d'acceptation et les scénarios de test.
  * Les développeurs et automaticiens pour automatiser les tests.

Le Gherkin devient ainsi un langage commun à l'ensemble de l'équipe.

==== Comment écrire en Gherkin ? ====

Le langage Gherkin est structuré par lignes et mots-clés :

  * Une ligne commence par un mot-clé.
  * Un mot-clé représente une étape du comportement utilisateur.
  * Une ligne = un mot-clé.

===== Les mots-clés fondamentaux =====

Les trois mots-clés principaux sont utilisés dans cet ordre :

<code>
Given
When
Then
</code>

  * **Given (Étant donné)** : décrit le contexte initial.
  * **When (Lorsque)** : décrit l'action réalisée par l'utilisateur.
  * **Then (Alors)** : décrit le résultat attendu.

===== Les mots-clés complémentaires =====

  * **And (Et)** : ajoute une condition.
  * **But (Mais)** : exclut ou précise une condition.

===== Les mots-clés de structuration =====

  * **Feature (Fonctionnalité)** : décrit la fonctionnalité ou la User Story.
  * **Scenario** : décrit un comportement attendu spécifique.

===== Les règles à respecter =====

==== La règle d'or ====

Toute personne, même étrangère au projet, doit comprendre le comportement décrit sans avoir besoin d'explications supplémentaires.

Si ce critère est respecté, la rédaction remplit pleinement son objectif.

==== Les trois règles fondamentales ====

=== 1. Un découpage clair ===

  * 1 User Story = 1 fonctionnalité.
  * 1 scénario = 1 comportement.

Si un scénario contient plusieurs ensembles de :

<code>
Given
When
Then
</code>

il est souvent préférable de le découper en plusieurs scénarios.

=== 2. Une syntaxe lisible ===

  * Respecter l'ordre : **Given → When → Then**.
  * Utiliser **And** et **But** lorsque nécessaire.
  * Éviter le vocabulaire technique et le code.
  * Utiliser l'indentation pour améliorer la lisibilité.

=== 3. Des titres de scénarios clairs ===

Des titres explicites permettent :

  * De vérifier rapidement la pertinence du scénario.
  * D'identifier les doublons.
  * De faciliter la maintenance.

**Conseil :** limiter le nombre de scénarios à environ 5 par User Story.

===== Exemple de rédaction Gherkin =====

==== Cas de test classique ====

Exemple :

Une personne souhaite acheter le tome 1 d'Harry Potter sur un site e-commerce nommé ''Fleury&Bott.com''.

==== Transformation en Gherkin ====

Pour améliorer la lisibilité, le comportement peut être découpé en deux scénarios :

  * Recherche d'un produit via la barre de recherche.
  * Accès à la fiche produit.

Exemple :

<code gherkin>
Feature: Recherche d'un livre

  Scenario: Recherche du tome 1 d'Harry Potter
    Given que l'utilisateur est sur la page d'accueil
    When il saisit "Harry Potter Tome 1" dans la barre de recherche
    Then les résultats correspondant à sa recherche sont affichés

  Scenario: Consultation de la fiche produit
    Given que les résultats de recherche sont affichés
    When l'utilisateur sélectionne le tome 1 d'Harry Potter
    Then la fiche détaillée du produit est affichée
</code>

===== Conclusion =====

Le langage Gherkin permet :

  * D'établir des règles de rédaction communes.
  * D'être compris par toutes les parties prenantes.
  * De décrire les comportements utilisateurs attendus.
  * De faciliter la communication entre les équipes agiles.