Gherkin

Le PO écrit une spec dans un document. Le développeur l'interprète à sa façon. Le QA teste autre chose. Résultat : trois personnes, trois compréhensions différentes du même besoin. Ce n'est pas un bug technique — c'est un bug de communication. Le langage Gherkin existe pour combler ce fossé.

Le fossé entre le besoin et le test

Dans la plupart des équipes, les spécifications vivent dans un document (Confluence, Notion, Google Docs) et les tests vivent dans le code. Ces deux mondes évoluent séparément. La spec dit "l'utilisateur peut ajouter un produit au panier", le test vérifie expect(cart.items.length).toBe(1). Quand la spec change, le test ne suit pas toujours. Quand le test échoue, personne ne sait si c'est la spec ou le code qui a tort.

Gherkin propose une solution : écrire les spécifications dans un format qui est à la fois lisible par un humain et exécutable par une machine.

Un langage naturel structuré

Gherkin est un langage de spécification qui utilise des mots-clés simples pour décrire le comportement attendu d'un système. Il se lit comme du français (ou de l'anglais) mais suit une structure stricte.

Les mots-clés principaux :

• Feature — décrit la fonctionnalité testée
• Scenario — un cas d'utilisation concret
• Given (Étant donné) — le contexte initial
• When (Quand) — l'action effectuée
• Then (Alors) — le résultat attendu
• And / But — pour enchaîner les étapes

Un exemple concret : le panier e-commerce

Feature: Gestion du panier d'achat
  En tant qu'utilisateur du site
  Je veux pouvoir gérer mon panier
  Afin de préparer ma commande
 
  Scenario: Ajouter un produit disponible au panier
    Given un produit "T-shirt bleu" en stock à 29.99€
    And un panier vide
    When j'ajoute le produit "T-shirt bleu" au panier
    Then le panier contient 1 article
    And le total du panier est 29.99€
 
  Scenario: Ajouter un produit en rupture de stock
    Given un produit "Casquette rouge" en rupture de stock
    And un panier vide
    When j'essaie d'ajouter le produit "Casquette rouge" au panier
    Then je vois le message "Ce produit n'est plus disponible"
    And le panier reste vide
 
  Scenario: Ajouter un produit déjà dans le panier
    Given un produit "T-shirt bleu" en stock à 29.99€
    And un panier contenant 1 "T-shirt bleu"
    When j'ajoute le produit "T-shirt bleu" au panier
    Then le panier contient 2 "T-shirt bleu"
    And le total du panier est 59.98€

Ce fichier est lisible par le PO, le développeur et le QA. Il n'y a aucune ambiguïté sur le comportement attendu. Et surtout — chaque scénario peut être exécuté automatiquement comme un test.

Le BDD : la méthodologie derrière Gherkin

Gherkin est le langage du Behavior-Driven Development (BDD), une méthodologie introduite par Dan North en 2006. Le BDD ne commence pas par le code — il commence par une conversation.

Le cycle BDD suit trois étapes :

1. Discovery — PO, dev et QA se réunissent (les "Three Amigos") pour explorer le besoin. On identifie les scénarios, les cas limites, les questions non résolues.
2. Formulation — Les scénarios identifiés sont écrits en Gherkin. C'est la spec vivante.
3. Automation — Les développeurs implémentent les "step definitions" qui lient chaque étape Gherkin au code de test.

// Step definition pour Cucumber.js
Given("un produit {string} en stock à {float}€", (nom, prix) => {
  produit = new Produit(nom, prix, true);
  catalogue.ajouter(produit);
});
 
When("j'ajoute le produit {string} au panier", (nom) => {
  panier.ajouter(catalogue.trouver(nom));
});
 
Then("le panier contient {int} article(s)", (count) => {
  expect(panier.nombreArticles()).toBe(count);
});
 
Then("le total du panier est {float}€", (total) => {
  expect(panier.total()).toBeCloseTo(total);
});

Les outils de l'écosystème

Les bénéfices concrets

Un langage partagé. PO, dev et QA lisent et écrivent les mêmes scénarios. Plus de traduction entre la spec et le test. Plus de "ce n'est pas ce que j'avais demandé".

Une documentation vivante. Les fichiers Gherkin sont à la fois la documentation fonctionnelle et les tests. Quand le code change, les scénarios sont mis à jour — la doc ne devient jamais obsolète.

Une couverture des cas limites. La conversation en Discovery force à penser aux edge cases avant d'écrire du code. "Et si le produit est en rupture ?" "Et si l'utilisateur ajoute 100 fois le même article ?"

Des tests de recette automatisés. Plus besoin de dérouler manuellement un cahier de recette. Les scénarios Gherkin s'exécutent en CI/CD.

Les pièges à éviter

Sur-spécifier. Écrire des scénarios Gherkin pour chaque micro-comportement rend la suite de tests ingérable. Réservez Gherkin aux comportements métier importants, pas aux détails techniques.

Tester l'implémentation. Un scénario Gherkin ne doit jamais mentionner de détails techniques (noms de tables, endpoints API, sélecteurs CSS). Il décrit le quoi, pas le comment.

Écrire du Gherkin sans conversation. Si le développeur écrit les scénarios seul, vous perdez l'essentiel du BDD. La valeur est dans la discussion entre les Three Amigos, pas dans le format du fichier.

Négliger la maintenance. Des scénarios obsolètes ou qui échouent sans raison érodent la confiance de l'équipe. Traitez vos fichiers Gherkin comme du code de production.

Gherkin n'est pas un outil de test — c'est un outil de communication. Il force une équipe à se mettre d'accord sur le comportement attendu avant d'écrire du code. Les tests automatisés ne sont que la conséquence naturelle de cette conversation. Dans la pyramide des tests, les scénarios Gherkin se placent au sommet : peu nombreux, focalisés sur le métier, et compréhensibles par tous.