Gherkin

Gherkin : Le langage clé pour un test clair et collaboratif

Le Gherkin est un langage structuré utilisé pour rédiger des scénarios de test de manière claire et compréhensible par toutes les parties prenantes d’un projet, y compris les équipes métier, les développeurs, les testeurs et les Product Managers. Il suit une syntaxe simple basée sur des mots-clés en langage naturel, permettant d’écrire des données et le comportement attendu d’un logiciel sous forme de test. Il est au cœur de l’approche BDD (Behavior-Driven Development), qui favorise une meilleure collaboration entre les équipes produit et techniques.

Principes du Gherkin

Le Gherkin repose sur une structure standardisée permettant de formaliser des tests sous un format lisible et interprétable par des outils d’automatisation comme Cucumber, un outil dont le nom fait référence aux concombres, symbolisant la simplicité du langage. Ce langage est conçu pour assurer une meilleure collaboration entre les équipes en utilisant des expressions naturelles et normalisées.

Un scénario Gherkin suit la structure suivante :

• Feature : Décrit la fonctionnalité testée.
• Scenario : Définit un cas d’usage spécifique.
• Given : Précise les conditions initiales et les données nécessaires.
• When : Décrit l’action déclenchante dans le test.
• Then : Indique le résultat attendu, souvent lié à des critères spécifiques.
• And/But : Ajoutent des précisions ou conditions supplémentaires.

Code d’exemple de Scénario Gherkin

Feature: Authentification d’un user  
  Afin d’accéder à la page "mon espace personnel"  
  En tant que user enregistré  
  Je veux pouvoir me connecter avec mon identifiant et mon mot de passe  

Scenario: Connexion réussie avec des identifiants valides  
  Given un user sur la page de connexion  
  And que son compte est actif  
  When il saisit un identifiant et un mot de passe corrects  
  Then il est redirigé vers son tableau de bord

Gherkin et Cucumber : Une association clé

Le Gherkin est principalement utilisé avec Cucumber, un outil permettant d’exécuter les tests automatisés à partir de fichiers .feature. Chaque étape du scénario est associée à une implémentation en code, ce qui permet de transformer des exigences métier en scénarios de test automatisé et d’assurer leur exécution à travers un script d’automatisation.

L’importance du mot-clé « Should » en Gherkin

Dans l’écriture des scénarios Gherkin, le mot « should » est souvent utilisé pour exprimer des attentes précises sur le comportement de l’application. Par exemple :

Then l'utilisateur **should** voir un message de confirmation

Ce mot-clé permet d’ajouter une couche d’intentionnalité, clarifiant ce que le produit doit accomplir.

Où écrire le Gherkin ?

Les scénarios Gherkin sont enregistrés dans un fichier au format .feature. Ce fichier contient plusieurs features, chacune décrivant une partie du comportement de l’application. L’association du Gherkin et de Cucumber assure une exécution efficace des tests et une meilleure traçabilité des exigences et des critères de validation, souvent intégrés dans un script qui pilote l’exécution des tests.

Exemples de fichier Gherkin

Un projet bien structuré en BDD contient plusieurs fichiers .feature, chacun se concentrant sur une fonctionnalité spécifique du produit. Quelques exemples :

• login.feature : Contient tous les scénarios liés à l’authentification d’un user.
• checkout.feature : Décrit les cas de test liés au processus de paiement.
• search.feature : Définit les comportements attendus lors de l’utilisation du moteur de recherche.

Le Gherkin, un langage international

Le Gherkin est disponible en plusieurs langues, y compris en anglais et en français, permettant aux équipes internationales de rédiger leurs scénarios de manière adaptée à leur contexte. Toutefois, les mots-clés Given, When, Then restent souvent utilisés en anglais même dans des projets francophones, car ils sont standards dans l’écosystème BDD.

L’origine du nom Gherkin

Le nom Gherkin, qui signifie « cornichon » en anglais, fait référence à l’outil Cucumber (qui signifie « concombres ») avec lequel il est souvent utilisé. Cette appellation ludique souligne l’idée d’un langage simple et structuré, facilitant l’écriture de test dans un format compréhensible par tous.

Avantages du Gherkin

• Lisibilité : Le format en langage naturel facilite la compréhension des scénarios par toutes les parties prenantes, y compris les Product Managers.
• Alignement entre métier et technique : Permet aux équipes produit et aux développeurs de parler un langage commun.
• Automatisation de test : L’intégration avec des outils d’automatisation permet de systématiser l’exécution des tests grâce à des scripts dédiés.
• Réutilisabilité : Les étapes étant standardisées, elles peuvent être réutilisées dans différents scénarios.

Limites du Gherkin

• Risque de scénarios trop détaillés : Une mauvaise structuration des étapes peut rendre les tests difficiles à maintenir.
• Discipline d’écriture nécessaire : Une rédaction imprécise peut générer des ambiguïtés.
• Dépendance aux outils d’automatisation : L’exécution des tests repose sur des frameworks comme Cucumber, qui nécessitent des scripts bien conçus.

Conclusion

Le Gherkin est un langage clé pour rédiger un test d’acceptation aligné avec les exigences métier. Son intégration dans des frameworks comme Cucumber facilite l’automatisation des scénarios et la communication entre les équipes. En structurant correctement les étapes, un user story peut garantir la fiabilité et l’efficacité des tests, assurant ainsi une validation continue des fonctionnalités du produit. Grâce à l’utilisation de fichiers bien définis et à une écriture rigoureuse utilisant des termes comme should, given, when ou then et des critères clairs, les tests deviennent des artefacts précieux pour l’ensemble du cycle de développement. Les scripts d’automatisation permettent de transformer ces tests en actions vérifiables, garantissant ainsi la qualité et la cohérence du produit.