Gherkin
Le langage de spécification BDD qui permet d'écrire des scénarios de test en langage naturel, compréhensibles aussi bien par les développeurs que par les parties prenantes non techniques.
Qu'est-ce que Gherkin ?
Imaginez que vous devez expliquer comment fonctionne une application à la fois aux développeurs qui vont la construire et aux utilisateurs qui vont s'en servir. Comment faire pour que tout le monde comprenne exactement la même chose ? C'est là qu'intervient Gherkin : un langage simple qui permet de décrire le comportement attendu d'un logiciel en utilisant des phrases compréhensibles par tous.
Gherkin est comme un traducteur universel entre le monde des affaires et celui de la technologie. Il permet d'écrire des scénarios qui décrivent précisément comment l'application doit se comporter dans différentes situations, en utilisant un format standardisé mais en langage naturel.
Ce que Gherkin apporte à votre projet
Communication claire
Un langage commun entre les parties prenantes métier, les développeurs et les testeurs, évitant les malentendus coûteux pendant le développement.
Documentation vivante
Des spécifications qui servent à la fois de documentation et de tests automatisés, garantissant que la documentation reste toujours à jour avec le code.
Tests automatisés
Transformation facile des spécifications en tests exécutables, permettant de vérifier en permanence que l'application fait bien ce qu'elle est censée faire.
Validation des exigences
Possibilité de vérifier très tôt que les besoins métier sont bien compris et correctement implémentés, réduisant les risques de développer les mauvaises fonctionnalités.
En résumé, Gherkin est un outil puissant qui permet de créer une compréhension partagée des fonctionnalités d'une application entre tous les acteurs d'un projet. Il transforme des phrases simples comme "Étant donné que je suis sur la page d'accueil, quand je clique sur connexion, alors je devrais voir un formulaire" en spécifications précises qui peuvent être comprises par tous et transformées en tests automatiques.
Fonctionnement technique
Gherkin est un langage spécifique au domaine (DSL) conçu pour décrire le comportement d'un logiciel sans spécifier comment ce comportement est implémenté. Il est au cœur du développement piloté par le comportement (BDD) et est utilisé avec des frameworks comme 
Cucumber, SpecFlow, 
Behat et autres.
Syntaxe et structure
Un fichier Gherkin (généralement avec l'extension .feature) est organisé selon une structure précise qui facilite à la fois la lisibilité humaine et l'interprétation par les outils d'automatisation :
- Feature: Décrit une fonctionnalité ou une capacité du système
- Background: Définit des étapes qui sont communes à tous les scénarios de la fonctionnalité
- Scenario: Décrit un cas de test spécifique
- Given-When-Then: Structure fondamentale pour décrire les étapes d'un scénario :
- Given (Étant donné) : Établit le contexte initial
- When (Quand) : Décrit l'action déclenchante
- Then (Alors) : Spécifie le résultat attendu
- And, But : Conjonctions pour chainer plusieurs étapes du même type
Exemples de Gherkin et cas d'usage
Exemple de base : Feature avec scénarios
Voici un exemple simple montrant la structure d'une fonctionnalité d'authentification avec deux scénarios : une connexion réussie et un échec de connexion.
# language: fr
Feature: Authentification utilisateur sur le site e-commerce
En tant qu'utilisateur inscrit
Je veux pouvoir me connecter au site
Afin d'accéder à mon compte et gérer mes commandes
Background:
Given le site e-commerce est accessible
And la base de données utilisateur est opérationnelle
Scenario: Connexion réussie avec identifiants valides
Given je suis sur la page de connexion
When je saisis "user@example.com" dans le champ email
And je saisis "password123" dans le champ mot de passe
And je clique sur le bouton "Se connecter"
Then je dois être redirigé vers la page "Mon compte"
And je dois voir le message "Bienvenue, User"
And mon nom d'utilisateur doit apparaître dans l'en-tête
Scenario: Échec de connexion avec mot de passe incorrect
Given je suis sur la page de connexion
When je saisis "user@example.com" dans le champ email
And je saisis "mauvais_mot_de_passe" dans le champ mot de passe
And je clique sur le bouton "Se connecter"
Then je dois rester sur la page de connexion
And je dois voir le message d'erreur "Identifiants incorrects"
And les champs de formulaire doivent être vidésScenario Outline : Tests paramétrés
Les Scenario Outlines permettent d'exécuter le même scénario plusieurs fois avec des données différentes, évitant la répétition de code.
# language: fr
Feature: Recherche de produits sur le site e-commerce
En tant qu'utilisateur
Je veux pouvoir rechercher des produits par différents critères
Afin de trouver rapidement ce que je cherche
Scenario Outline: Recherche de produits par catégorie et mot-clé
Given je suis sur la page d'accueil du site
When je sélectionne la catégorie "<catégorie>"
And je saisis "<mot_clé>" dans la barre de recherche
And je clique sur le bouton rechercher
Then je dois voir au moins <nombre> résultats
And tous les résultats doivent appartenir à la catégorie "<catégorie>"
And tous les résultats doivent contenir "<mot_clé>" dans leur description ou titre
Examples:
| catégorie | mot_clé | nombre |
| Électronique | smartphone | 5 |
| Vêtements | chemise | 10 |
| Cuisine | robot | 3 |
| Jardin | tondeuse | 2 |
| Livres | programmation | 7 |Data Tables : Organisation de données complexes
Les tables de données permettent de fournir des entrées structurées pour les étapes d'un scénario.
# language: fr
Feature: Panier d'achat
En tant qu'utilisateur
Je veux pouvoir ajouter plusieurs produits à mon panier
Afin de les commander en une seule fois
Scenario: Ajouter plusieurs produits au panier et vérifier le total
Given je suis connecté sur le site e-commerce
And mon panier est vide
When j'ajoute les produits suivants à mon panier:
| Produit | Quantité | Prix unitaire |
| Smartphone Galaxy S22 | 1 | 799.99€ |
| Coque de protection | 2 | 19.99€ |
| Chargeur rapide | 1 | 29.99€ |
Then mon panier doit contenir 4 articles au total
And le sous-total doit être de 869.96€
And les frais de livraison standard doivent être affichés
And je dois pouvoir accéder à la page de commandeFonctionnalités avancées : Tags, Background et scénarios multiples
Un exemple plus complet utilisant des tags pour catégoriser les scénarios, un background commun et plusieurs scénarios liés.
# language: fr
@paiement @critique
Feature: Processus de paiement et confirmation de commande
En tant qu'utilisateur avec des articles dans mon panier
Je veux pouvoir finaliser ma commande avec différentes méthodes de paiement
Afin de recevoir les produits que j'ai sélectionnés
Background:
Given je suis connecté avec l'utilisateur "client_test@example.com"
And j'ai les produits suivants dans mon panier:
| Produit | Quantité | Prix unitaire |
| Écran LCD 24" | 2 | 199.99€ |
| Clavier mécanique | 1 | 89.99€ |
And je suis sur la page de paiement
@carte_bancaire
Scenario: Paiement réussi par carte bancaire
When je sélectionne "Carte bancaire" comme méthode de paiement
And je renseigne les informations de carte suivantes:
| Numéro de carte | Date d'expiration | CVV |
| 4111 1111 1111 1111 | 12/25 | 123 |
And je valide mon paiement
Then je dois être redirigé vers la page de confirmation
And je dois recevoir un email à "client_test@example.com" avec les détails de ma commande
And le statut de ma commande doit être "Paiement accepté"
@paypal
Scenario: Paiement réussi via PayPal
When je sélectionne "PayPal" comme méthode de paiement
And je clique sur "Payer avec PayPal"
And je me connecte sur PayPal avec:
| Email | Mot de passe |
| paypal@example.com | testpwd123 |
And je confirme le paiement sur PayPal
Then je dois être redirigé vers la page de confirmation
And le statut de ma commande doit être "Paiement accepté"
And ma commande doit être enregistrée dans l'historique de mon compte
@echec_paiement
Scenario: Échec de paiement par carte expirée
When je sélectionne "Carte bancaire" comme méthode de paiement
And je renseigne les informations de carte suivantes:
| Numéro de carte | Date d'expiration | CVV |
| 4111 1111 1111 1111 | 01/20 | 123 |
And je valide mon paiement
Then je dois voir le message d'erreur "Carte expirée"
And je dois pouvoir choisir une autre méthode de paiement
And mon panier doit toujours contenir mes produitsBonnes pratiques pour écrire du Gherkin efficace
- Restez centrés sur le comportement - Décrivez ce que le système doit faire, pas comment il le fait
- Utilisez le langage du domaine - Employez la terminologie métier comprise par toutes les parties prenantes
- Un scénario = un comportement spécifique - Testez un seul aspect du comportement par scénario
- Évitez la duplication - Utilisez Background, Scenario Outlines et Step Definitions pour éviter de répéter du code
- Gardez les scénarios indépendants - Chaque scénario doit pouvoir s'exécuter seul sans dépendre d'autres scénarios
- Nommez clairement - Donnez des titres descriptifs à vos features et scénarios pour faciliter la compréhension
- Respectez la structure Given-When-Then - Suivez ce format pour maintenir la clarté des scénarios
Intégration avec les frameworks de test
Les fichiers Gherkin ne sont pas directement exécutables. Ils doivent être associés à du code qui implémente les étapes décrites. Ce code est généralement appelé "Step Definitions" et fait le lien entre les phrases en langage naturel et le code qui teste réellement l'application.
Gherkin est utilisé principalement avec les frameworks suivants :
- Cucumber - Le framework BDD le plus populaire, disponible pour Java, JavaScript, Ruby, etc.
- SpecFlow - L'équivalent de Cucumber pour .NET
- Behat - Framework BDD pour PHP
- Behave - Framework BDD pour Python
- Cypress-cucumber-preprocessor - Extension permettant d'utiliser Gherkin avec Cypress
L'intégration de Gherkin dans un processus de développement agile permet de créer une boucle de feedback continue, où les spécifications écrites en collaboration deviennent des tests automatisés qui vérifient en permanence que l'application répond aux attentes métier définies.
Cas d'usage
Spécification collaborative
Ateliers de spécification collaboratifs (ou "Specification by Example") où les développeurs, testeurs et représentants métier définissent ensemble les comportements attendus de l'application.
Tests d'acceptation automatisés
Transformation des scénarios Gherkin en tests automatisés de bout en bout qui vérifient que l'application répond aux critères d'acceptation définis par le métier.
Documentation vivante
Création d'une documentation toujours à jour car liée directement au code et aux tests, servant à la fois de référence technique et de documentation fonctionnelle.
Rapports de couverture fonctionnelle
Génération de rapports visuels montrant la couverture des fonctionnalités métier par les tests, permettant d'identifier les zones à risque non couvertes.
Intégration continue
Exécution automatique des tests BDD basés sur Gherkin dans les pipelines CI/CD, garantissant que chaque livraison respecte les comportements attendus.
Validation réglementaire
Documentation claire et tests vérifiables pour les applications dans des domaines réglementés (finance, santé, etc.), facilitant les audits et la conformité.
