Le BDD (Behaviour Driven Development, ou développement piloté par le comportement) est une pratique popularisée par Dan North en 2003, dérivée du TDD (Test Driven Development, ou développement piloté par les tests), dont elle est complémentaire.
Pourquoi utiliser le BDD ? Précisément pour remédier aux problèmes courants liés aux spécifications en mode Agile :
Le BDD est donc une pratique agile visant à synchroniser les différents acteurs développant une fonctionnalité avec ce qu’elle est censée faire. L’objectif du BDD est de concevoir des tests d’acceptation illustrant le comportement de la fonctionnalité, à l’aide de méthodes telles que les « 3 amigos » ou le « example mapping ». L’approche BDD se déroule généralement en trois étapes : découverte, formulation et automatisation.
Les acteurs sont alignés à l’aide d’exemples co-conçus qui illustrent le comportement de la fonctionnalité : il s’agit de la découverte des cas d’utilisation, souvent réalisée grâce à la réunion des « 3 amigos » (profils client, développeur et testeur), qui permet d’établir une compréhension commune du besoin et de rédiger des scénarios d’acceptation pour valider les critères d’acceptation.
Ces exemples sont formulés à l’aide d’un langage commun, Gherkin, facilement compréhensible par les différents profils des « 3 amigos ». Ce langage Gherkin est conçu pour rédiger des tests structurés en langage naturel, et a priori compréhensibles par tous. Les tests Gherkin s’écrivent à l’aide de quatre éléments de base : GIVEN / WHEN / THEN … AND (GIVEN un certain contexte, WHEN j’effectue une action, THEN j’obtiens un résultat 1 AND un résultat 2).
À partir de cette formulation structurée (et formatée) du comportement de la fonctionnalité, il est possible d’intégrer ces exemples dans un outil logiciel, tel que Cucumber par exemple, qui interprétera ce langage Gherkin pour exécuter des tests d’acceptation automatisés, adaptés à ces exemples. C’est l’étape de l’automatisation.
Le BDD est désormais utilisé dans de nombreuses entreprises pour tester le comportement de certaines fonctionnalités en étroite collaboration avec les utilisateurs. Mais même si le BDD sert à parvenir à une compréhension commune des besoins, il subsiste un certain nombre de malentendus autour de cette pratique Agile, qui peuvent conduire à certains abus. Quels sont-ils ?
Avant le sprint, la pratique BDD consiste, par le biais de la découverte, à valider une compréhension commune de l’exigence par tous les acteurs impliqués. Cette compréhension est formulée à travers des exemples, des critères d’acceptation et des scénarios d’acceptation, qui sont ensuite implémentés dans un outil de conception et d’exécution de tests automatisés.
La mise en œuvre des différentes étapes de cette approche permettra de lutter contre la dérive du BDD et, surtout, contre la confusion qui règne actuellement autour des différents termes liés au concept de BDD.