L’approche BDD vous connaissez ? C’est encore un acronyme du type xDD ? Et bien oui, ENCORE un ! Le BDD, pour Behavior Driven Development est une méthode qui encourage la collaboration entre le product owner, les développeurs, les intervenants non-techniques participants à la co-construction d’un projet de logiciel. Cette approche a été formalisée en 2003 par Dan North comme une extension au Test Driven Development.
En effet, le BDD consiste littéralement à étendre le TDD en écrivant non plus du “code”, qui est compréhensible uniquement par des développeurs, mais des scénarios d’utilisation compréhensibles par toutes les parties prenantes impliquées dans le projet.
Autrement dit, l’approche BDD consiste à écrire des tests compréhensibles qui décrivent le comportement attendu du système et que tout le monde peut comprendre : Ces tests se formalisent sous la forme de scénarios d’utilisation.
Mais écrire des scénarios d’utilisation, c’est utile ?
Mais pourquoi doit-on prendre du temps pour écrire des scénarios ? Quelles sont les avantages par rapport aux spécifications traditionnelles ?
- Collectif et collaboratif : L’écriture des scénarios peut se faire de manière collective. Le product owner, les testeurs, développeurs, clients, équipe support, …: tout le monde peut participer à l’expression du besoin, puisque celui-ci se fait en langage naturel. Toutes les questions soulevées, par le client ou par le développeur, peuvent faire l’objet de scénarios dédiés. Les scénarios décrivent alors le fonctionnement réel de l’application, et le traitement des cas aux limites.
- Plus de clarté, moins d’incertitudes : En illustrant chaque cas d’utilisation par des exemples concrets, les règles métiers sont moins abstraites et mieux comprises.
- Diminution de l’effet silo : En écrivant des tests que tout le monde peut comprendre, les clients s’assurent que les développeurs ont bien compris les besoins métiers. L’approche BDD constitue un véritable outil de communication rapprochant développeurs et personnes du métiers en facilitant les échanges autour d’un comportement applicatif explicite, visible et partagé.
- Un filtre à fonctionnalité déchet : A chaque fois qu’une nouvelle fonctionnalité est (d)écrite, son utilisation est illustrée par plusieurs exemples et cas de tests concrets. Cela force à réfléchir sur la fonctionnalité et son utilisation. Les fonctionnalités ainsi décrites sont ainsi plus challengées ce qui permet de rassurer le développeur sur l’intérêt de son développement et permet aussi “d’optimiser le travail non fait”.
- Un besoin réalisé plus proche du besoin exprimé : Le scénario sert à focaliser les discussions et la réalisation sur les attentes du client. En guidant l’écriture du code, celui-ci devient plus fonctionnel et plus imprégné du métier.
- Discuter avec un langage commun et facilement interprétable : Ces mots clés (Given, When, Then, As a, In order to …) permettent de définir une grammaire commune qui sert à la fois à structurer le scénario en langage naturel
- Préparer le terrain pour un beau code : Et oui ! Faire du BDD c’est faire de la qualité ! Vous allez découvrir comment dans la suite 🙂
Concrètement le BDD c’est quoi ?
Nous venons de voir certains avantages de l’approche BDD… Vous voulez en profiter ? Nous allons maintenant voir comment !
BDD – La Syntaxe
Le BDD s’exprime sous la forme suivante (en Anglais ou en Français) :
- Étant donné : Given
- Quand : When
- Alors : Then
- Et : And
Basé sur cette structure sémantique, un scénario décrit succinctement une situation théorique.
Par exemple :
- Étant donné qu‘un utilisateur non connecté laisse un commentaire sur le site coach-agile.com
- Quand le commentaire dépasse 1000 caractères (si si si vous pouvez faire le test 🙂 )
- Alors le commentaire ne doit pas être sauvegardé
- Et l’utilisateur doit voir un message d’erreur
En multipliant les scénarios autour des fonctionnalités, vous allez profiter des avantages décrits en première partie !
En effet, multiplier les scénarios permet, par exemple, d’atteindre l’avantage 4 décrit plus haut. Si une fonctionnalité exprimée est :
- En tant qu’utilisateur connecté,
- Je veux pouvoir payer mon panier sur le site coach agile
- Afin de recevoir mes produits
Le fait de décrire différents scénarios va permettre de filtrer les fonctionnalités déchets, d’affiner le besoin etc :
Scénario 1 :
- Étant donné qu’un utilisateur connecté souhaite payer son panier
- Quand il souhaite payer en visa
- Alors …
Scénario 2 :
- Étant donné qu’un utilisateur connecté souhaite payer son panier
- Quand il souhaite payer en paypal
- Alors …
Vous commencez à percevoir tout l’intérêt de l’approche BDD ? Nous allons collectivement éviter les trous dans la raquette, affiner le besoin, filtrer les fonctionnalités déchets etc…
Cependant, c’est bien joli d’écrire des scénarios… mais comment transforme t-on tout ça en code maintenant ?
Le TDD est la prolongation naturel du BDD ?
Même si “temporellement”, le BDD est l’extension du TDD, dans une logique de développement nous passons à l’étape TDD “test-driven development” après la rédaction des scénarios.
Voici comment les deux fonctionnent ensemble. Vous allez dans cet ordre :
- Identifier des comportements (“behaviors” en anglais) avec BDD.
- Écrire des tests pour ces comportements avec TDD.
Dans cette approche combinée (ATDD nous voilà) , vous vous êtes déjà facilité la vie car vous avez formalisé les comportements qu’il faut développer pendant la phase de rédaction des scénarios.
Ainsi, dans la “seconde phase” TDD, vous allez :
- Transformer les scénarios écrits dans la phase BDD en tests.
- Transformer ces tests en code en écrivant les solutions les plus basiques possibles pour faire passer vos tests.
Une fois que vous avez écrit un bon test avec le code le plus simple possible, vous avez fini — et vous pouvez continuer en déroulant le scénario/test suivant !
Lorsque l’on transforme un scénario d’utilsation en test, il y a trois règles à respecter, selon Robert Martin :
- Vous devez écrire un test qui échoue avant d’écrire votre code lui-même.
- Vous ne devez pas écrire un test plus compliqué que nécessaire.
- Vous ne devez pas écrire plus de code que nécessaire, juste assez pour faire passer le test qui échoue.
Ces 3 règles fonctionnent ensemble et font partie d’un processus qui s’appelle le cycle rouge-vert-refactor (“red-green-refactor” en anglais).
Cycle Rouge-vert-refactor
Le cycle rouge-vert-refactor vous guidera dans l’écriture de vos tests à partir de vos scénarios. Voyons d’où vient son nom.
- Rouge : Vous écrivez un test simple qui échouera avant même d’avoir du code qui l’accompagne. Le test échoue, évidemment, sans le code. Du coup, le test est rouge.
- Vert : Vous écrivez le code le plus simple possible pour faire passer le test, même si le code est un peu ridicule ou simplifié. Le test réussit, il est donc vert.
- Refactor : le code que vous avez écrit pour faire passer le test est peut être illogique ou trop simple. Il faut faire un refactor de ce code maintenant si possible.
Mais cet article n’a pas pour vocation de rentrer dans le détail du TDD. Pour en apprendre plus sur le sujet, je vous invite à lire cet article d’open class room : Apprenez le test driven developpement
Un petit récap’
Pour finir, re-voyons ensemble et très briévement l’intéret et le fonctionnement de cette approche combinée BDD / TDD comportant 2 phases :
Phase 1 – BDD – Rédaction des scénarios :
La première étape dans ce processus, c’est de détailler les comportements que vous attendez des fonctionnalités.
Pour rédiger ces comportements applicatif ou scénarios, utilisez la syntaxe pré-définie : Étant donné, Quand, Alors, et Et (Given, When, Then, And). Ces scénarios ainsi rédigés permettront de guider le processus d’écriture des tests et donc du code.
Phase 2 – TDD – Rédaction des tests :
Après la phase BDD, vous écrirez des tests correspondants aux scénarios précédemment formalisés. Les tests que vous écrivez au début échoueront certainement parce que vous n’avez pas encore écrit le code pour la fonctionnalité que vous testez. Puis vous rédigerez le code faisant passer ces tests au vert !
Pour terminer, cette approche bien qu’efficace et ayant des gains certains a déjà 15 ans ! Pourtant elle n’est pas encore très répandue… Et vous, vous l’utilisez ? Partagez votre expérience dans les commentaires !
