Écrire de meilleurs user stories avec Gherkin et Cucumber

.

Écrire des tests unitaires automatisés pour les logiciels que nous construisons peut sembler être une grande quantité de travail de base sans gain clair. Cependant, les avantages à long terme pour la santé, le bonheur et la rapidité de votre équipe dépassent largement l’investissement initial. Parmi de nombreux autres avantages, les tests automatisés permettent d’attraper les bogues, de permettre le déploiement continu et de faciliter la participation des développeurs à un code peu familier.

Cucumber est un outil qui nous permet de créer des tests logiciels automatisés d’une manière facile à écrire et à lire. Bien que de nombreuses équipes produit peinent à faire décoller les tests automatisés (n’ayant peut-être jamais entendu parler d’outils comme Cucumber), presque toutes ont involontairement tâté de l’un de ses composants clés – Gherkin.

Lorsqu’elle est utilisée judicieusement, l’écriture de critères d’acceptation sous forme de Gherkin est un excellent moyen pour les équipes de définir et de s’accorder sur ce que  » fait  » signifie pour les fonctionnalités qu’elles construisent. Malgré sa simplicité, Gherkin est un langage très nuancé. Avec cette nuance vient beaucoup de confusion sur ce qui sépare une déclaration bien écrite d’une déclaration mal écrite, en particulier pour les personnes novices en Gherkin.

Isolement, les bizarreries de Gherkin peuvent sembler déroutantes, mais lorsqu’elles sont vues dans le contexte des tests automatisés de Cucumber, ces subtilités ont beaucoup plus de sens. Cet article passe en revue la façon dont Gherkin et Cucumber s’intègrent ensemble afin que vous puissiez voir comment utiliser Gherkin plus efficacement aujourd’hui. À la fin de cet article, vous apprendrez comment fonctionne une implémentation complète de Gherkin + Cucumber et comment la constitution d’une bibliothèque de scénarios Gherkin bien écrits ouvre la voie aux tests automatisés.

Gherkin est un langage spécifique au domaine pour écrire des critères d’acceptation qui comporte cinq énoncés principaux :

1. Scenario – une étiquette pour le comportement que vous allez décrire
2. Given – l’état initial du scénario
3. When – une action spécifique que l’utilisateur effectue
4. Then – un résultat testable, généralement causé par l’action dans When
5. And – cela continue l’un des trois autres opérateurs

Ensemble, ces déclarations décrivent toutes les actions qu’un utilisateur doit entreprendre pour effectuer une tâche et le résultat de ces actions.

Par exemple, un exemple Gherkin du monde réel pourrait ressembler à ceci:

Scenario: User clicks the link
Given I am on the homepage
When I click the provided link
Then I should see the link click confirmation

Ou pour généraliser, à ceci:

Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

Généralement, le chef de produit écrit les critères d’acceptation Gherkin avant que l’équipe ne commence à travailler sur une fonctionnalité. Le fait d’avoir des critères d’acceptation décrits dans une structure facile à lire et à comprendre permet aux développeurs et aux concepteurs de comprendre beaucoup plus facilement le flux d’utilisateurs prévu. Cela est précieux en soi, mais ce n’est qu’une petite partie de la valeur d’un Gherkin bien structuré. Après tout, il existe de nombreuses façons efficaces d’écrire des descriptions de fonctionnalités (comme : As a ___ I want to ___ so that ___) qui peuvent faciliter la communication.

Ces autres approches ont leur place et, dans de nombreux cas, sont compatibles avec Gherkin. Cependant, une fois que nous dépassons le stade de l’assurance qualité manuelle et que nous entrons dans celui des tests automatisés, la véritable valeur de Gherkin apparaît au premier plan. Avec quelques techniques astucieuses, les scénarios Gherkin que nous écrivons en anglais peuvent être automatiquement traduits en code automatisé testable. Pour voir ce que je veux dire, jetons un coup d’œil rapide au grand frère de Gherkin – Cucumber.

Expressions régulières

La traduction des scénarios Gherkin en code utilise une technologie appelée Expressions régulières, ou comme on l’appelle communément, Regex.

Le problème que résout Regex est de trouver des mots, des phrases ou des caractères spécifiques dans un corps de texte. Pour atteindre cet objectif, les créateurs de Regex ont défini un ensemble de caractères et de symboles qui représentent la logique derrière la correspondance des parties du texte. Par exemple, $ est utilisé pour marquer la fin d’une chaîne de caractères. À ce titre, l’expression régulière fox$ correspondrait à silver fox (car les trois dernières lettres sont f-o-x) mais pas à foxy(car la dernière lettre est y).

Cucumber utilise Regex pour scanner les scénarios que nous définissons pour les mots-clés de Gherkin (ScenarioGivenWhenThen, et And) et les phrases qui les suivent. Lorsque Cucumber trouve une phrase qu’il reconnaît dans l’un de nos scénarios à l’aide de Regex, il traduit cette phrase en code en utilisant quelque chose appelé Définitions d’étape.

Définitions d’étape

Les fichiers de définition d’étape sont comme un dictionnaire de langue étrangère. Ils donnent à notre suite de tests un moyen de traduire les étapes du scénario anglais en code que nous pouvons exécuter. Dans la plupart des équipes, les développeurs qui construiront la fonctionnalité écrivent les définitions d’étape.

Les fichiers de définition d’étape ressemblent à quelque chose comme ceci :

La première déclaration dit « chaque fois que vous trouvez la chaîne ‘Je vais sur la page d’accueil’, alors exécutez la fonction visit root_path« .

La deuxième déclaration dit « chaque fois que vous trouvez la chaîne ‘Je devrais voir le message de bienvenue’ alors nous attendons que la page actuelle ait le texte ‘Hello Cucumber’ quelque part sur elle ».

Chaque étape d’un scénario doit avoir une définition d’étape afin que la suite de tests automatisés sache comment traduire notre anglais en code. Au fil du temps, vous écrirez des centaines de ces définitions d’étape, dont beaucoup sont réutilisables dans l’ensemble de votre suite de tests (comme la première étape définie ci-dessus).

Caveat : la réutilisation des fonctions n’est possible que si nous utilisons une seule phrase pour une seule action. Si nos scénarios utilisent à la foisI go to the homepage et I visit the homepage de manière interchangeable, nous devons alors maintenir deux définitions d’étapes distinctes pour la même action. Ce code dupliqué rend notre suite de tests plus difficile à maintenir et viole le principe DRY (don’t repeat yourself) du développement logiciel.

Au fur et à mesure que nos applications et nos suites de tests grandissent, nos définitions d’étapes et notre nombre de scénarios grandissent en même temps. Cela peut rapidement devenir désordonné et devenir accablant. Pour aider à organiser nos suites de tests, nous utilisons des fichiers de fonctionnalités.

Fichiers de fonctionnalités

Pour aider à gérer la complexité d’une grande suite de tests, nous regroupons nos scénarios Gherkin dans des fichiers de fonctionnalités. Les fichiers de fonctionnalités sont comme une liste de contrôle virtuelle pour s’assurer que votre logiciel fonctionne. En plus des scénarios nécessaires pour tester une fonctionnalité, les fichiers de fonctionnalités ont également une courte description de la fonctionnalité et toute règle métier ou information supplémentaire qui aide à décrire ce que fait la fonctionnalité.

Un fichier de fonctionnalités pourrait ressembler à quelque chose comme ceci:

Feature: Some terse yet descriptive text of what is desired
Textual description of the business value of this feature
Business rules that govern the scope of the feature
Any additional information that will make the feature easier to understand
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too Scenario: A different situation
...

Une application peut (et devrait) avoir de nombreux fichiers de fonctionnalités pour décrire comment vos fonctionnalités fonctionnent. Ces tests fonctionnent ensemble pour vous donner un aperçu de la santé de votre application.

Sortie

Lorsque vous exécutez votre suite de tests en ligne de commande à l’aide de Cucumber, vous obtiendrez une sortie ressemblant à ceci :

$ cucumber -s
Using the default profile...
Feature: Hello CucumberScenario: User sees the welcome message
When I go to the login page
Then I should see the welcome message1 scenario (1 passed)
2 steps (2 passed)
0m0.148s

Ou pour quelque chose de plus tangible :

$ cucumber -s
Using the default profile...
Feature: Google Homepage SearchScenario: User sees the header
Given I’m on the homepage
Then I see the headerScenario: User can search with "Google Search”
Given I’m on the homepage
When I type "random page” into the search field
And I click the Google Search button
Then I go to the random page search resultsScenario: User can search with "I’m Feeling Lucky”
Given I’m on the homepage
When I type "random page” into the search field
And I click the I’m Feeling Lucky button
Then I go to a random pageScenario: User can see the Terms and Conditions
...15 scenarios (15 passed)
87 Steps (87 passed)
0m3.141s

Prendre connaissance de la sortie de l’exécution de votre suite de tests vous donne un moyen immédiat de vérifier votre application. Il peut montrer où vos changements ont cassé un élément de l’ancienne fonctionnalité ou où la nouvelle fonctionnalité ne fonctionne pas comme prévu. Cela facilite l’identification et la correction de ces problèmes afin que vous puissiez expédier en toute confiance.

Wrapping Up

L’utilisation de Gherkin pour écrire des scénarios permet de montrer simplement les flux que le produit doit avoir. Les fichiers de fonctionnalités aident à organiser ces flux en morceaux logiques. Cucumber scanne ces morceaux et nous donne une lecture en direct des éléments de notre logiciel qui fonctionnent et de ceux qui ne fonctionnent pas.

Une suite de tests complète où chaque fonctionnalité a un fichier de fonctionnalités et un ensemble de scénarios est un outil puissant. Il permet d’attraper facilement les bugs dans les nouvelles fonctionnalités, d’éviter d’introduire des bugs dans les anciennes fonctionnalités, et de communiquer les progrès avec les parties prenantes. Pour faire court, il automatise certains des plus grands délais entre la construction d’une fonctionnalité et sa mise entre les mains de vos utilisateurs.

L’utilisation de Gherkin et de Cucumber n’est pas la seule façon de construire des tests de critères d’acceptation automatisés, mais c’est une structure facile à mettre à l’échelle. Vous pouvez commencer à écrire Gherkin immédiatement et, à mesure que votre équipe mûrit et se développe, commencer à ajouter des fichiers d’étapes et des tests automatisés avec Cucumber. Lorsqu’ils sont utilisés efficacement, Cucumber et Gherkin nous donnent un chemin clair (et itératif !) vers des tests unitaires complets et automatisés.