Behaviour Driven Development

Objectif

Le Behaviour Driven Development est une pratique de spécification par l'exemple. On écrit les cas réels que la solution devra traiter, chacun sous la forme d'un scénario en trois temps: l'état des choses avant, l'événement déclencheur, le résultat observable après. Le scénario est du texte, lisible par une personne du métier qui n'a jamais ouvert un outil de développement et assez structuré pour qu'un moteur de test l'exécute tel quel.

Le problème traité est une perte d'information par traduction. Un besoin énoncé par le métier est reformulé en exigence par l'analyste, puis en conception par le développeur, puis en cas de test par le testeur. Chaque reformulation est une occasion d'interpréter de travers, et l'écart se constate à la recette, au moment où la correction coûte le plus cher. Le BDD supprime les relais en faisant tenir les quatre points de vue dans un seul texte, dicté par le métier et exécuté par l'outillage. Dan North présente cette langue commune comme le premier acquis de la pratique, avant toute automatisation.

Le livrable est un jeu de scénarios rattaché à un élément de backlog, complété à mesure que l'équipe découvre les cas que le premier tour avait laissés de côté. L'Agile Extension résume l'intention en trois effets: plus de valeur, moins de gaspillage et une communication plus directe entre les parties prenantes et l'équipe de livraison, obtenus en concentrant l'analyse sur le comportement que le client attend. Les termes behaviour driven development, acceptance test driven development et specification by example s'emploient couramment l'un pour l'autre, sans que le guide en trace la frontière.

Usage

Quand l'utiliser

• Livraison itérative: fixer le comportement attendu élément par élément, juste avant la construction.
• Métier et équipe sans vocabulaire commun: là où l'écart entre l'attendu et le livré se répète, l'exemple concret ferme l'interprétation que l'énoncé général laisse ouverte.
• Tests d'acceptation à automatiser: le scénario écrit une fois se relit comme spécification et s'exécute comme test.
• Traçabilité à démontrer devant un auditeur ou un régulateur: la suite exécutée atteste quel comportement est vérifié et quand il l'a été.
• Conception à cadrer: dérouler la grammaire sur une solution déjà esquissée tient la discussion sur un comportement précis.

Quand ne pas l'utiliser

• Règles métier combinatoires: le nombre de scénarios explose et devient intraçable, passer par une table de décision.
• Exigences non fonctionnelles chiffrées: un comportement ne porte ni temps de réponse ni volumétrie, écrire des critères d'acceptation mesurés.

Description

La pratique est née dans le prolongement du test driven development. Dan North a construit en 2003 un cadre de test, JBehave, qui remplaçait « test » par « comportement », parce que les équipes qu'il accompagnait butaient sur les mêmes questions: que faut-il tester, jusqu'où et à quel moment. Avec Chris Matts, il a formulé en 2004 le gabarit « étant donné, quand, alors » pour l'analyse des exigences. L'article de 2006 qui fixe la pratique porte donc d'abord sur la langue: le gain revendiqué est un vocabulaire partagé par les analystes, les testeurs, les développeurs et le métier.

Les trois éléments

Les exemples sont des situations vécues, apportées par les parties prenantes. Le responsable de produit les fournit et, ce faisant, clarifie sa propre pensée: un cas particulier qu'il croyait évident se révèle discutable dès qu'il faut en écrire le résultat. Le business analyst facilite cette découverte et répond du caractère complet du jeu d'exemples, que personne d'autre ne surveille. Tous les exemples ne relèvent pas du périmètre de l'incrément en cours.

La grammaire, appelée Gherkin, est le moule dans lequel l'exemple entre. Le gabarit que retient l'Agile Extension est volontairement pauvre, quatre mots-clés, ce qui le rend lisible sans apprentissage et analysable par une machine. Gherkin en compte quelques autres, dont le scénario type assorti de son tableau de valeurs (Scenario Outline et Examples), qui factorise les variantes ne différant que par leurs données. Cette pauvreté est aussi une contrainte d'analyse: un exemple qui refuse d'entrer dans le moule est le signe d'un besoin encore flou ou d'un scénario qui en contient deux.

L'exécution ferme la boucle: plusieurs produits lisent des scénarios dans ce format et les relient à du code de test. La spécification devient alors un test qui échoue dès que le comportement change, ce qui est le seul mécanisme qui signale de lui-même qu'une documentation a cessé d'être vraie. Sans cette étape, la technique reste utile pour la conversation et la suite de scénarios vieillit comme n'importe quel document.

La grammaire, mot-clé par mot-clé

Un scénario porte un titre qui nomme le cas traité, puis des lignes introduites par les quatre mots-clés du gabarit. La règle la plus structurante est celle du déclencheur unique: un seul QUAND par scénario. Deux événements dans un même scénario signifient deux scénarios, et l'auteur qui les fusionne ne sait plus lequel des deux a échoué. Les conditions de départ et les résultats attendus se composent en revanche librement par des ET.

La séance Three Amigos et les questions « et si »

La séance habituelle réunit trois rôles, d'où son nom de Three Amigos: le responsable de produit, qui apporte le cas et arbitre ce que la solution doit faire; le testeur, qui cherche les cas que personne n'a envisagés; le développeur, qui interroge le déclencheur et les données que le scénario suppose en place. Chacun regarde le même exemple depuis un angle que les deux autres n'ont pas, et le désaccord surgit au moment où il se règle en une phrase.

Le travail du business analyst dans cette séance a un nom dans le guide: poser les questions « et si » et « et qu'en est-il de » qui font apparaître les scénarios manquants. Chaque question porte sur une variation d'une ligne ÉTANT DONNÉ. Et si le solde ne suffisait pas? Et si le bénéficiaire n'était pas encore enregistré? Et si l'opération tombait un jour férié cantonal? Chaque réponse est soit un scénario de plus, soit une règle métier que personne n'avait écrite. C'est là que la technique rapporte le plus. Ces questions sont aussi les premières à sauter quand la séance est écourtée.

Conduire la technique

1. Choisir l'élément de backlog et réunir les trois rôles
   Une séance porte sur un seul élément de backlog. Sans le responsable de produit, la séance produit des suppositions; sans le testeur, elle ne produit que le chemin nominal.
2. Faire raconter les exemples par le métier
   On demande des cas vécus, avec leurs valeurs réelles. Un dossier traité la semaine passée vaut mieux qu'une généralité.
3. Poser les questions « et si »
   Chaque variation d'une condition de départ est un scénario candidat. On note aussi les réponses qui sortent du périmètre de l'incrément, sans les mettre en forme.
4. Mettre en forme
   Un titre qui nomme le cas, un seul QUAND, les conditions et les résultats composés par ET. Les valeurs figurent dans le texte, en clair.
5. Vérifier la couverture
   Le jeu contient au minimum le cas nominal, les cas de refus et les cas limites où une règle bascule. Un scénario dont le résultat ne se déduit pas des conditions énoncées est incomplet.
6. Attacher les scénarios à l'élément de backlog
   Ils en deviennent les critères d'acceptation et servent de base à la démonstration de fin d'itération.
7. Automatiser et rejouer
   Chaque scénario est relié à du code de test et rejoué à chaque intégration. Un scénario qui n'est jamais exécuté n'est plus qu'un commentaire.
8. Élaguer
   À chaque changement de règle, les scénarios concernés sont réécrits ou supprimés. Une suite qu'on laisse grossir devient illisible avant de devenir fausse.

La place du scénario parmi les critères d'acceptation

Un scénario en étant donné, quand, alors est un format de critère d'acceptation parmi d'autres. Les critères d'acceptation et d'évaluation traitent de la question générale: à quelles conditions une solution est-elle acceptée et sur quelles échelles plusieurs candidates se comparent-elles. Le BDD est la pratique collaborative qui produit un de ces formats, celui qui est lisible par le métier et exécutable. Un projet écrit ses critères de disponibilité, de coût ou de conformité dans d'autres formes et emploie le scénario là où c'est un comportement qui se juge.

Ce qui fait échouer la technique

Le scénario écrit dans le vocabulaire de l'écran

« Quand je clique sur le bouton Valider de l'onglet Paiements » décrit une interface là où le scénario doit décrire un comportement. Le scénario casse à la première refonte de l'interface alors que la règle métier n'a pas bougé, et le métier cesse de le relire parce qu'il n'y reconnaît plus son affaire. On écrit l'acte, « quand je valide le virement », et l'on laisse à la couche technique le soin de savoir où se trouve le bouton.

Le scénario manquant

C'est la limite que le guide nomme en premier: sans quelqu'un pour poser les questions « et si », des cas passent à la trappe. La suite passe entièrement alors qu'elle est incomplète, ce qui est plus dangereux qu'une absence de tests, parce qu'elle rassure.

La suite qui déborde

Quand les règles métier sont combinatoires, les scénarios se multiplient plus vite qu'on ne les suit, jusqu'à une suite dont personne ne connaît plus le contenu et que l'on n'ose plus toucher. Les variantes de valeurs se rangent dans un scénario type et son tableau. Les combinaisons de règles se traitent en table de décision, et le BDD garde les quelques scénarios qui illustrent le comportement d'ensemble.

Le scénario écrit après le code

Le scénario décrit alors le comportement que le code produit déjà. Il passe toujours et il donne au projet l'illusion d'une couverture.

Le Gherkin sans la conversation

Une équipe qui rédige seule ses scénarios obtient des fichiers correctement formés et retrouve le défaut que la technique existe pour supprimer: une spécification écrite sans le métier. La grammaire ne vaut que par la séance qui la remplit.

Considérations IA

Sur cette technique, un modèle de langue rend quatre services. Il génère une liste de questions « et si » à partir d'un élément de backlog et de ses règles métier, contre laquelle la séance se mesure. Il met en forme: on lui donne le compte rendu ou la transcription de la séance et il en tire des scénarios structurés que la séance corrige. Il détecte les doublons et les recouvrements dans une suite devenue trop grosse pour être relue. Il aligne les trois langues pour une équipe qui travaille en français, en allemand et en anglais, la grammaire étant assez pauvre pour survivre à la traduction.

Les limites tiennent à ce qu'un exemple est. L'exemple appartient au métier: c'est un cas qui s'est produit dans cette organisation, avec ses montants, ses seuils et ses exceptions maison. Un modèle sommé d'en produire fabriquera un plafond de virement, un délai de révocation ou un montant en CHF qui ont l'air justes et ne correspondent à aucune règle de la maison. Le scénario faux sera automatisé aussi fidèlement qu'un vrai. Un scénario généré que personne ne discute reproduit le défaut du Gherkin sans conversation. Les seuils qui engagent de l'argent ou la conformité se vérifient contre la règle écrite. Enfin, les exemples réels portent des données personnelles, noms de clients, numéros AVS, IBAN, montants: ils s'anonymisent avant tout envoi vers un modèle public.

Exemples

Une banque de détail suisse ajoute une limite de virement journalière à son e-banking. La séance produit deux scénarios: celui qui passe et celui que la limite arrête.

C'est la forme habituelle d'un jeu de scénarios utile: des variantes serrées autour d'une condition qui bascule. Le lecteur retrouve le résultat par le calcul, CHF 5'000 de limite moins CHF 4'000 déjà utilisés laissent CHF 1'000, ce qui refuse un virement de CHF 1'200. Écrire un seul scénario aurait obligé à énoncer la bascule sous forme de règle générale, c'est-à-dire à quitter l'exemple pour l'abstraction que la technique cherche à éviter.

La séance a produit davantage que ces deux textes. Le troisième cas soulevé, « et si le virement était en devise étrangère », a fait apparaître une règle que personne n'avait écrite: la limite journalière s'apprécie sur la contre-valeur en francs, au cours du jour. La règle a rejoint la documentation du produit et attend son propre scénario. Le développeur a demandé ce que devient la limite au passage de minuit: elle se remet à zéro au bouclement de la journée bancaire, ce qui ajoutera une ligne ÉTANT DONNÉ le jour où ce cas sera écrit. Un dernier candidat, la limite relevée par téléphone auprès du conseiller, sort du périmètre de l'incrément: il est inscrit au backlog et reste sans mise en forme, faute d'un comportement à livrer cette fois-ci.

Visualisations

La technique produit du texte structuré, des lignes et des mots-clés, donc les deux artefacts se rendent en tableaux: la grille des quatre mots-clés avec leur correspondance dans le test unitaire et le jeu de scénarios de la section précédente, qui est le livrable. Deux idées demandent en revanche un dessin. La première est le triple usage du même texte, un exemple qui devient un scénario d'où partent trois flèches, vers la documentation lue par le métier, vers le critère d'acceptation attaché à l'élément de backlog et vers le test rejoué à chaque intégration. La seconde est la séance à trois rôles, avec la question propre à chacun et les questions « et si » qui font naître les scénarios manquants.

Coût

Outils

Le point de départ est un tableau blanc ou un document texte partagé pendant la séance. Un scénario est du texte court et le gabarit tient en quatre mots: la contrainte utile est de le rendre visible de tous.

Les outils de gestion de backlog (Jira, Azure DevOps, GitLab et leurs équivalents) hébergent les scénarios comme critères d'acceptation de l'élément auquel ils se rattachent. C'est la place la plus économique quand l'automatisation n'est pas encore en jeu, parce que le scénario suit l'élément dans la priorisation et dans la démonstration de fin d'itération.

Les outils de spécification par l'exemple (Cucumber, SpecFlow, Behat, JBehave et leurs équivalents) lisent des fichiers de scénarios et les relient à du code de test. Ils apportent aussi les mesures que la seule rédaction ne donne pas: quels scénarios sont couverts, lesquels échouent, quelles exigences restent sans scénario. Leurs conventions de syntaxe diffèrent, et l'on choisit celui qui parle le langage de la plateforme de l'équipe.

Deux compléments comptent autant que l'outil de test. Le gestionnaire de versions garde les fichiers de scénarios avec le code qu'ils spécifient, de sorte qu'une modification de comportement et sa spécification voyagent dans le même commit. La chaîne d'intégration continue rejoue la suite à chaque livraison de code et fait tomber un scénario devenu faux avant qu'un lecteur ne s'y fie.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.2 Behaviour Driven Development: le cadrage pour le business analyst, les trois éléments (exemples, grammaire Gherkin, exécution), la règle du QUAND unique, la séance Three Amigos, l'usage du scénario comme critère d'acceptation d'une story et les limites énoncées, scénario manquant faute de questions « et si », explosion combinatoire et entretien de la suite.
• Dan North, Introducing BDD, Better Software, mars 2006: la source de la technique. Le passage du vocabulaire du test à celui du comportement, le gabarit « étant donné, quand, alors » formulé avec Chris Matts pour l'analyse des exigences et la langue commune aux analystes, aux testeurs, aux développeurs et au métier.
• Agile Alliance, What is BDD (Behavior Driven Development)?: l'attribution de la technique à Dan North et Chris Matts et le rattachement du BDD aux pratiques de test driven development et d'acceptance test driven development.