8 meilleures façons d’écrire des scénarios BDD que toute l’équipe peut lire

Introduction

La plupart des équipes qui s’essayent au développement axé sur le comportement n’ont pas de difficultés avec les outils. Ils ont eux-mêmes du mal avec les scénarios. Les fichiers de fonctionnalités deviennent longs, les étapes deviennent vagues ou trop techniques et, en quelques mois, plus personne en dehors de l’équipe d’assurance qualité ne les lit. À ce stade, BDD est devenu discrètement un moyen plus lent d’écrire des tests réguliers.

La bonne nouvelle est que rédiger des scénarios clairs est une compétence qui suit une poignée de règles que vous pouvez commencer à utiliser dès aujourd’hui. Vous en trouverez ci-dessous huit qui font la plus grande différence.

Tout d’abord, un rappel rapide

BDD est un moyen pour les développeurs, les testeurs et les parties prenantes de l’entreprise de se mettre d’accord sur la façon dont une fonctionnalité doit se comporter avant que quiconque n’écrive du code. Cet accord est capturé sous forme d’exemples concrets, généralement au format Given / When / Then, et un cadre de développement axé sur le comportement comme Cucumber, Reqnroll ou pytest-bdd connecte chaque étape au code. Par conséquent, les exemples s’exécutent sous forme de tests automatisés.

Cela signifie que chaque scénario s’adresse à deux publics : les personnes qui doivent comprendre la règle et un exécuteur de test qui doit l’exécuter. Les bons scénarios servent les deux. Les mauvais ne servent généralement qu’au testeur, et c’est là que les problèmes commencent.

1. Décrivez le comportement, pas les clics

L’erreur la plus courante consiste à écrire des scénarios sous forme de scripts d’interface utilisateur :

• Lorsque je clique sur le bouton « Commander ».
• Et je tape « SAVE10 » dans le champ du coupon.
• Et je clique sur « Appliquer ».

Cela vous indique ce que l’utilisateur a appuyé, et non quelle est la règle métier. Il se casse également à chaque fois que l’interface change. Comparez-le avec :

• Lorsque le client applique le coupon « SAVE10 ».
• Le total de la commande est alors réduit de 10 %.

La deuxième version survit à une refonte et un chef de produit peut confirmer qu’elle est correcte en quelques secondes. Le clic se produit toujours, mais il réside dans le code de définition d’étape auquel il appartient.

2. Un scénario, une règle

Si un scénario nécessite plus d’un « Alors » pour avoir un sens, il teste souvent deux comportements à la fois. En cas d’échec, vous ne saurez pas quelle règle a enfreint. Divisez-le pour que chaque scénario prouve exactement une chose. Le nom devrait rendre cette chose évidente, comme « Le coupon expiré est rejeté » plutôt que « Test du coupon 3 ».

3. Utilisez des exemples concrets, pas des abstractions

« Étant donné qu’un utilisateur a une commande importante » invite à un débat sur ce que signifie « grande ». « Étant donné un panier totalisant 250 $ » ne l’est pas. Les valeurs réelles exposent très tôt les cas extrêmes. Si votre équipe ne parvient pas à se mettre d’accord sur le nombre exact, c’est que vous venez de découvrir une exigence qui n’a jamais été vraiment définie, et il est bien moins coûteux de la trouver maintenant qu’après la sortie.

4. Gardez « donné » sur l’état, pas sur les étapes de configuration

La section Donné doit décrire le monde tel qu’il est avant l’action, et non les étapes pour y arriver. Au lieu d’une chaîne du type « Étant donné que j’ouvre l’application, que je me connecte et que je vais dans les paramètres », écrivez « Étant donné un utilisateur connecté sur le forfait gratuit ». La façon dont cet état est créé appartient au code de définition de l’étape, pas au scénario. Cela permet de conserver des scénarios courts et de modifier la logique de configuration sans toucher à chaque fichier de fonctionnalités.

5. Utilisez les plans de scénario pour les variations

Lorsque la même règle s’applique à plusieurs entrées, ne copiez pas le scénario cinq fois. Utilisez un aperçu de scénario avec un tableau d’exemples :

Aperçu du scénario : les frais d’expédition dépendent du total de la commande

• Étant donné un panier totalisant .
• Lorsque le client passe à la caisse.
• Puis les frais de port .

Exemples :

Total de la commande	Expédition
30 $	5 $
75 $	2 $
100 $	gratuit

Le tableau sert également de documentation. N’importe qui peut le scanner et voir la règle de tarification en un coup d’œil, et l’ajout d’un nouveau cas est un changement d’une seule ligne.

6. Créez un vocabulaire d’étapes partagé

Si une personne écrit « Compte tenu d’un utilisateur enregistré » et une autre écrit « Compte tenu d’un utilisateur qui s’est inscrit », vous conservez désormais des définitions en deux étapes pour la même idée. Au fil du temps, cela rend les suites lentes à changer et difficiles à faire confiance.

Convenez d’une formulation standard pour les étapes courantes, conservez une courte liste de références dans votre référentiel et révisez les nouvelles étapes de la même manière que vous révisez le code. De nombreux frameworks peuvent également vous avertir des étapes inutilisées ou en double, ce qui permet de garder le vocabulaire bien rangé.

7. Étiquetez des scénarios pour que vous puissiez exécuter ce qui compte

À mesure qu’une suite se développe, l’exécution de chaque scénario à chaque validation devient lente. Les balises vous permettent de regrouper les scénarios par objectif, par exemple @smoke pour les chemins critiques, @payments pour un domaine spécifique, ou @slow pour tout ce qui touche aux systèmes externes. Votre pipeline CI peut ensuite fumer des scénarios sur chaque demande d’extraction et sur la suite complète tous les soirs.

Les balises facilitent également la communication. Un propriétaire de produit qui souhaite savoir ce qui est couvert pour les paiements peut filtrer selon cette balise au lieu de lire chaque fichier.

8. Écrivez des scénarios ensemble, avant le code

Les scénarios écrits par un développeur une fois la fonctionnalité terminée ne sont que des tests avec un formatage supplémentaire. La vraie valeur de BDD vient de la conversation : un développeur, un testeur et quelqu’un à qui appartient l’exigence passent quinze minutes sur des exemples avant de commencer le travail. Cette courte session détecte des malentendus qui autrement surgiraient lors de la révision du code, de l’assurance qualité ou de la production.

Signes que vos scénarios nécessitent un nettoyage

Même les suites bien gérées dérivent. Surveillez quelques signes avant-coureurs. Les scénarios qui échouent après des modifications de l’interface utilisateur alors que la règle métier reste la même signifient généralement que les étapes sont trop liées à l’interface. Les fichiers de fonctionnalités que personne en dehors de l’ingénierie n’a ouverts depuis des mois suggèrent que les scénarios ont cessé d’être un langage partagé. Et si la suite prend tellement de temps que les développeurs l’ignorent localement, vous avez probablement trop de scénarios en cours de travail que les tests unitaires ou API pourraient gérer plus rapidement.

Lorsque vous les repérez, planifiez un bref nettoyage : fusionnez les étapes en double, supprimez les scénarios qui ne reflètent plus les règles réelles et déplacez les cas extrêmes de bas niveau vers des couches de test plus rapides.

Une liste de contrôle rapide avant de commettre un scénario

• Un non-développeur pourrait-il le lire et confirmer que la règle est correcte ?
• Teste-t-il exactement un comportement ?
• Toutes les valeurs sont-elles concrètes ?
• Est-ce que cela passerait toujours après une refonte de l’interface utilisateur, tant que la règle reste inchangée ?
• Réutilise-t-il les étapes existantes lorsque cela est possible ?
• Est-il étiqueté pour fonctionner au bon moment ?

Pensées finales

Les scénarios lisibles sont ce qui sépare BDD qui aide une équipe de BDD qui devient discrètement un étagère. Concentrez-vous sur les règles plutôt que sur les clics, gardez chaque scénario petit et concret et rédigez-les ensemble avant le début du développement. Faites-le de manière cohérente et vos fichiers de fonctionnalités deviennent quelque chose de rare dans un logiciel : une documentation qui reste précise car elle s’exécute sur chaque version.