Gherkin est un langage structuré en texte clair qui permet également d’être utilisé pour créer des user story.
Certaines équipes l’utilisent dans les approches BDD (Behavior-Driven Development) pour décrire les comportements attendus d’une application sous forme de scénarios compréhensibles.
A tord ou à raison? Le BDD est une notion plus complexe que l’écriture d’un langage.
Pourquoi utiliser Gherkin ?
L’utilisation de Gherkin présente plusieurs avantages :
- écrit en langage naturel, il est compréhensible par tous (développeurs, testeurs, chefs de projet, business analysts, etc.).
- intégré avec des outils comme :
- Cucumber (Java, JavaScript, Ruby, Python…)
- SpecFlow (C#)
- Behave (Python)
- Behat (PHP)
- encourage une meilleure communication entre les équipes métier et technique.
- les scénarios écrits en Gherkin servent de documentation
- et également de base pour vos tests automatisés car vous pouvez utiliser cucumber pour faire le lien entre votre code et les spécifications
Syntaxe de base de Gherkin
Gherkin repose sur une structure simple composée de mots-clés en anglais (ou dans d’autres langues supportées) :
Feature : décrit la fonctionnalité testée
Les termes utilisés sont :
Scenario : décrit un cas de test spécifique
Given – When – Then : structure du scénario
- Given : Contexte initial (prérequis)
- When : Action effectuée
- Then : Résultat attendu
Background : contexte commun à plusieurs scénarios
Outline et Examples : paramétrisation des scénarios
Pour éviter la duplication, Scenario Outline permet de tester plusieurs cas en utilisant des valeurs différentes.
Vous pouvez voir le code ci-dessous :
Pour quel contexte Gherkin est pertinent ?
- Projets agiles, avec des équipes pluridisciplinaires.
- Produits où la valeur métier prime sur la technique.
- Projets de longue durée où la documentation vivante est un vrai enjeu.
- Environnements où la collaboration entre PO, testeurs et développeurs est déjà en place ou souhaitée.
Les bonnes pratiques pour écrire des scénarios Gherkin sont :
- éviter le jargon technique
- éviter les scénarios trop longs : un scénario doit tester un seul comportement.
- Gherkin décrit ce qui doit être testé, pas comment.
- Réutiliser les étapes
Le Gherkin représente une véritable valeur ajoutée lorsqu’il est utilisé à bon escient : il structure la communication, clarifie les attentes métier et facilite l’automatisation des tests.
Mais mal maîtrisé, il peut rapidement devenir contre-productif : scénarios trop nombreux, redondants, trop techniques ou détachés des besoins réels, ce qui alourdit inutilement le projet.
Lorsqu’on utilise un outil comme Jira, l’intégration de Gherkin peut apporter une vraie cohérence dans la gestion des exigences et des tests, notamment via des plugins comme Xray ou Zephyr.
Cependant, si les scénarios Gherkin sont rédigés sans collaboration, sans revue, ou en étant uniquement dictés par une logique technique, on court le risque de transformer ce langage métier en une usine à gaz illisible, où les cas de test perdent leur fonction première : servir la compréhension et la validation du besoin