BDD en bref

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

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-is-share-understanding.jpg

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 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 (BA) ou des spécialistes de l'assurance qualité (QA), 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 de structurer les conversations autour des "comportements" attendus serait un moyen d'impliquer 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.

Examples-what-if.jpg

Inspirations de BDD

BDD trouve ses origines chez les praticiens de l'eXtreme Programming (XP) qui cherchaient un moyen d'impliquer toutes les perspectives (y compris BA et QA) dans les conversations sur ce qu'il fallait construire.

C'est en grande partie grâce à Ward Cunningham, inventeur du wiki et de nombreuses pratiques XP, qui a développé en 2003 un framework de tests appelé FIT qui permettait aux gens du métier de spécifier des tests dans des tableaux en utilisant des feuilles de calcul. À peu près à la même époque, Brian Marick écrivait des choses concernant le fait d'exprimer les tests sous la forme d'exemples.

L'outillage pour supporter le BDD a d'abord évolué chez JBehave avec Liz Keogh comme collaboratrice active et plus tard chez Cucumber.

Ce que BDD n'est pas

Le BDD consiste à découvrir ce qu'il faut construire pour aider à enrichir le comportement. BDD n'est pas un framework Agile ou une approche de gestion de projet. Les équipes qui utilisent Scrum ou Kanban avec BDD trouveront quoi mettre dans leurs backlogs et leurs tableaux à des fins de planification. Vous voudrez peut-être même mesurer le nombre de scénarios BDD livrés au lieu de la vélocité, mais ces scénarios sont souvent trop fins pour répondre à des objectifs de planification des versions.

Lectures complémentaires

Sites Web :

Livres :

Articles :

Veuillez ajouter des commentaires pour indiquer d'autres ressources intéressantes sur le sujet. Merci !