Tout savoir sur le Behavior Driven Development

Pour continuer la série d’articles qu’Adimeo consacre aux méthodologies applicables aux projets de développement d’applications web, le Behavior Driven Development (BDD) est le sujet analysé aujourd’hui.

Analysé et expliqué, afin d’en saisir les enjeux et les avantages dans le contexte concret d’un projet.

On ne saurait trop que conseiller au lecteur de lire également l’article consacré au Test Driven Development (TDD) qui apporte des notions utiles pour bien comprendre le BDD et disposer de points de « comparaison » pertinents.

Mais commençons par donner une définition précise du Behavior Driven Development, sujet principal de cet article.

Qu’entend-t-on par « comportement » ou par « behavior » ?

Dans la notion de « développement piloté par le comportement ;», il convient de donner une bonne définition du terme important dans cette formule : le « comportement ».

D’après la littérature autorisée sur le sujet, le « comportement » est souvent décrit comme celui du produit à développer. Ou même, à une échelle plus petite, le « comportement » d’une fonction.

On peut ici trouver le sens de « comportement » assez imprécis, voir mal adapté au sujet. Un produit logiciel, une application, un site, une fonctionnalité ou même une fonction n’a pas, du moins dans notre langue française, un « comportement », mais plutôt un « résultat », et même en jargon un peu technique, une valeur de retour, des données de sorties, etc.

Dans ce sens, le BDD serait assez proche du TDD, car les tests mis en jeu dans cette méthodologie se préoccupent justement des « résultats » d’une fonction, d’une autre, et d’un ensemble dans un complète fonctionnalité.

Les comportements des utilisateurs au cœur de la méthode.

Le terme « comportement » s’applique bien mieux à la notion d’ « utilisateurs ». Et c’est justement ce que propose la méthode BDD : mettre les utilisateurs, leurs attentes et leurs usages au cœur du projet.

On comprend la vertu d’une telle démarche quand on sait qu’il vaut mieux un projet qui réponde à 100 % aux attentes des utilisateurs, même s’il n’était techniquement pas « très bon », plutôt que l’inverse.

On sait aussi d’expérience que dans une phase de développement d’un projet, le nœud du problème se trouve dans la transcription d’un besoin utilisateur, d’une user story, en un livrable opérationnel 100% conforme.

Le Behavior Driven Development est justement une méthodologie qui facilite cet effort de transcription. En donnant une gamme d’outils méthodologiques s’appliquant à décrire, documenter, illustrer et faire comprendre les « comportements » réels des utilisateurs, le BDD apporte des solutions utiles aux développeurs. Ces outils sont :

• L’utilisation, dans la documentation fournie aux développeurs, d’exemples concrets, décrivant des comportements pour une fonctionnalité ou un ensemble de fonctionnalités, jusqu’à l’échelle de l’unité de code.
• Une formalisation de ces exemples sous forme d’un langage (ou d’un métalangage) qui rationnalise les exemples et aide à leur compréhension dans un but d’application technique.
• L’utilisation opportune de ces exemples comportementaux décrits en langage formalisé au sein de tests automatisés vérifiant les développements réalisés.

On l’aura compris, les tests d’acceptation sont au cœur de la pratique du BDD : ils décrivent des comportements, sont écrits dans un langage formalisé (du Gherkin par exemple) et sont automatisés dans leur rôle de validation des livrables implémentés.

Quelle organisation pour le BDD ?

Le BDD ne se résume pourtant pas aux seuls tests d’acceptation.

Une organisation spécifique est nécessaire, notamment car la mise en œuvre des tests d’acceptation, ceux décrivant le comportement du produit à livrer, nécessite des connaissances métiers dont ne disposent pas les développeurs.

Le BDD implique donc largement toutes les « parties prenantes », métier, marketing, … Ce sont ces intervenants qui vont avoir la charge de concevoir (si ce n’est d’implémenter) les comportements décrits par les tests d’acceptation.

Le BDD impose donc de faite une forte participation des « métiers » au côté de la « technique ». Ce principe vertueux est déjà bien compris des pratiques agiles et il trouve toute son application dans le BDD.

Conseils pour l’application du BDD ?

Au-delà de cet aspect organisationnel, l’application du BDD passe par quelques éléments concrets et pragmatiques :

• Même si vouloir impliquer toutes parties prenantes dans des aspects proches de la technique, il est efficace et pragmatique qu’un « facilitateur » au profil technique organise et « filtre » les interventions de chacun ;
• Même si vouloir former les intervenants « métiers » à Gherkin (par exemple) est louable, les tests d’acceptation restent assez techniques et il est bon de disposer d’un ou plusieurs « traducteurs » au profil technique capable de « coder » les tests d’acceptation ;
• Le BDD s’appuie naturellement sur le TDD qui doit être maîtrisé en préalable par l’équipe technique ;
• Le BDD trouve un levier très efficace dans les principes de « conception pilotée par le domaine » (DDD ou Domain Driven Design) et donc dans les langages faits pour la description de « domaines métiers » (DSL ou Domain Specific Language) ;
• ... et si concrètement ces DSL ne sont pas majoritaires dans les pratiques et compétences techniques des développeurs, une solution de substitution très valable est de mettre en place une démarche de développement tirant le meilleur parti d’un design orienté objet intelligent et rigoureux.

En conclusion, le Behavior Driven Development est une méthodologie qui vient en compléter d’autres et notamment le TDD. On constate une fois encore le bénéfice des tests automatisés qui sont à la fois des outils techniques et un support méthodologique. Ici utilisé dans la volonté de rapprocher les attentes du métier et des utilisateurs des problématiques techniques… au plus proche du code et du travail de développeur.

Les tests techniques vous intéressent ? Je vous conseille de lire également mon article sur les tests unitaires. 😉

Crédits photos :

• Abu Hanifah
• fizkes
• Worawut Prasuwan