BDD en bref

Auteur : Rachel Davies
Source : BDD in a Nutshell
Date : 10/03/2012

---

Traducteur : Fabrice Aimetti
Date : 04/04/2019

---

Traduction :

Vendredi, j'ai discuté avec Katie, elle travaille dans un département où les équipes essaient d'appliquer le développement piloté par le comportement (BDD). Elle n'a pas encore participé à l'atelier de formation de Matt Wynne sur le BDD et elle cherche des articles sur le sujet pour expliquer de quoi il s'agit. J'ai donc rédigé ce billet pour expliquer ce qu'est le BDD et rassembler quelques liens pour en savoir plus.

Qu'est-ce que BDD ?

Le B dans BDD signifie Behaviour, le comportement souhaité du logiciel à développer. La partie DD est l'abréviation de Driven-Development (piloté par le comportement). BDD est une approche pour construire une compréhension commune sur le logiciel à construire en travaillant sur des exemples.

J'ai dessiné ce schéma de base pour illustrer l'idée de base.



BDD est assez simple, décrivez ce que vous voulez que le système fasse en donnant des exemples de comportement. Travaillez de l'extérieur vers l'intérieur pour mettre en oeuvre ces comportements en utilisant les exemples pour valider que vous êtes ce que vous êtes en train de construire.

Il n'est pas nécessaire de réunir toute l'équipe, mais il est utile d'avoir différentes perspectives pour étoffer les exemples. Le client (qui peut être un Scrum Product Owner) décrit ce qu'il veut et les développeurs posent des questions afin de disposer de suffisamment de détails sur le comportement pour pouvoir le mettre en oeuvre. Si vous avez des analystes métiers ou des spécialistes de l'assurance qualité, ils peuvent vous aider à faire émerger les détails des différents scénarios.

Comme TDD mais encore plus

Les exemples sont souvent transformés en tests automatisés et la pratique du BDD suit la même idée de base que le développement piloté par les tests d'acceptation (ATDD), où les tests d'acceptation sont élaborés pour chaque user story et automatisés à mesure que le logiciel est construit. Matt Wynne dit : "Le BDD est en fait du TDD réalisé correctement."

BDD est plus que du TDD parce qu'il met l'accent sur la collaboration avec les gens du métier. Dan North, à l'origine du surnom BDD, avait remarqué que les gens du métier restaient silencieux dans les conversations sur les "tests" car ceux-ci semblaient trop techniques. Il espérait que le fait d'encadrer les conversations sur les "comportements" serait un moyen d'engager l'équipe entière.

Langage universel

Pour s'assurer que toute l'équipe comprenne ce que l'on veut, nous décrivons le comportement dans un langage non technique. Nous prenons soin d'utiliser des noms qui reflètent le langage universel utilisé par les gens du métier, un des principes de base du Domain-Driven Design (Conception pilotée par le domaine] expliqué par Eric Evans et résumé dans Domain-Driven Design Quickly.

En fin de compte BDD consiste à construire une compréhension commune, vous faites mal du BDD si les seules personnes qui lisent les exemples sont les développeurs. J'ai l'impression d'avoir vu cette mise en oeuvre de BDD dans quelques endroits, regardez l'image ci-dessous. BDD est bien plus qu'un moyen d'automatiser les tests et si c'est tout ce que vous avez à l'esprit, un framework de tests unitaires pourrait vous donner une batterie de tests plus rapides.