BDD est une élaboration des pratiques TDD (développement par les tests) et ATDD (développement par les tests client).
Au lieu de parler de “tests”, une personne utilisant BDD préfèrera le terme “spécifications”. Il s’agit en fait de réunir dans un même document
des exigences (User Stories) exprimés selon le formalisme rôle-fonction bénéfice et des scénarios ou exemples exprimés selon le canevas given-when-then, ces deux notations étant les plus lisibles.
En mettant l’accent sur le mot “spécifications”, BDD cherche à fournir une réponse unique à ce que nombre d’équipe Agiles considèrent comme deux activités séparées: l’élaboration de tests unitaires et de code “technique” d’une part, l’élaboration de tests fonctionnels (servant à formaliser les exigences) et de “fonctionnalités” d’autre part. Plutôt que parler de “test unitaire d’une classe”, une personne ou une équipe utilisant BDD préfère dire qu’elle fournit les “spécifications du comportement (behaviour) de la classe”. Cela se traduit par une plus
grande attention portée au rôle documentaire de ces spécifications: leur
nom doit être parlant et, complété par leur description structurée par le
canevas given-when-then, doit pouvoir servir de documentation technique.
Plutôt que parler de “test fonctionnel” on préfèrera “spécifications du comportement du produit”; par ailleurs le volet technique de BDD est
complété par un ensemble de techniques favorisant la conversation avec
les interlocuteurs responsables de la définition du produit. En supplément des techniques de refactoring utilisées dans TDD, l’approche BDD prête, en matière de conception, une attention particulière à la répartition des responsabilités ce qui conduit à favoriser la technique dite de “mocking”.
En synthèse, BDD consiste à augmenter TDD et ATDD d’un certain
nombre de principes supplémentaires:
- appliquer le principe des “cinq pourquoi” à chaque User Story
proposée pour en comprendre l’objectif - raisonner “de l’extérieur vers l’intérieur”, c’est-à-dire toujours
implémenter le comportement qui contribue le plus directement à cet objectif - décrire ces comportements dans des notations accessibles à tous: experts fonctionnels, développeurs, testeurs
- appliquer ces techniques jusqu’aux plus bas niveaux de
description du logiciel, en étant attentif à la répartition des
comportements entre classes
Erreurs courantes
- bien que son créateur, Dan North, explique avoir conçu BDD
pour répondre à des difficultés récurrentes lors de
l’enseignement de TDD, il faut bien constater que BDD
mobilise un plus grand nombre de concepts que TDD, et il
semble difficile d’envisager qu’un programmeur novice soit
formé d’abord à BDD sans s’être préalablement familiarisé avec
TDD - il est parfaitement possible d’appliquer BDD sans outils
particuliers, et indifféremment du langage: l’erreur serait d’y voir un sujet purement technique ou de réduire la pratique à
l’utilisation d’un outil
Aller plus loin
JOYEUX ANNIVERSAIRE BDD !
