La pratique BDD (Behavior Driven Development) est un concept défini en 2003 par "Dan North", Cette pratique consiste à écrire les tests en se basant sur le comportement attendu du système suite à la demande ou l'User Story en question, ce comportement est compréhensible par tout le monde (tous les acteurs du l'écosystème).
Le concept BDD est une élaboration des autres pratiques : Les TDD (Test Driven Development ) que j'ai déjà décrit dans un article publié sur le Blog, et la pratique ATDD (Acceptance Test Driven Development) que je vais la décrire dans un article ultérieurement.
Cette pratique favorise le travail collaboratif des différents rôles, et vise la concentration et la focalisation de tout les acteurs (Développeurs, testeurs, parties prenantes, utilisateurs finaux, ...Etc.) sur la qualité du produit et le comportement attendu par le système.
L'objectif est de réunir tout le monde au tour d'une table pour étudier et analyser ensemble le comportement du système par rapport à une User Story par le biais d'un langage basé sur des phrases compréhensibles par tout le monde. cela va permettre une fluidité importante dans la communication et la négociation des critères d'acceptation d'une demande ou User Story.
A la fin de la réunion, tout le monde va sortir avec la même compréhension du besoin, la même vision, même stratégie de test à faire, ce qui va réduire le nombre des aller-retour d'une part, et augmenter la qualité des livrable d'autre part,
Le langage "Guerkin" (La syntaxe reconnue par l'outil Cucumber) est l'un des langages de programmation recommandé pour l'écriture des tests, car il se base sur une syntaxe naturelle proche du langage humain, et compréhensible par tout le monde.
Cette pratique de tests est très répandue dans le monde agile car elle présente plusieurs avantages, en occurrence :
Un champ et cadre adéquat pour communiquer et discuter avec les parties prenantes et les experts fonctionnels.
Une génération automatique d'une documentation technique à partir des spécifications fonctionnelles.
Décomposition et bonne compréhension du comportement du système d'une manière collective.
Une vision unique et partagé du produit et son comportement entre les différents acteurs, et avec l'utilisation des exemples réels et concrets.
Une meilleure qualité des livrables et moins de retours et bugs en recette ou production.
Conclusion :
La pratique BDD est parmi les bonnes pratiques agile permettant d'avoir une meilleure compréhension du besoin, très bonne qualité des livrables, moins de bug en recette et production, mais en parallèle elle demande l'implication de tout le monde et tous les acteurs dans un projet agile.
Il est possible d'appliquer et utiliser la pratique BDD sans outils spécifique, et indifféremment du langage de programmation déployé.
Comments