Introduction

S’il n’est pas le premier cité des trois classiques : TDD, BDD, DDD, le BDD est pourtant un des éléments fondamental lorsqu’on souhaite travailler dans un climat sain, et se juxtapose de manière naturelle avec le TDD de par l’apport d’empathie et de compréhension de l’univers social du groupe de développeurs qui travaille sur un projet. 

Le BDD est le résultat d’une problématique liée à la mauvaise communication entre les différentes parties prenantes d’un projet, à savoir le manque de questionnement en amont du projet pouvant amener à un lot de questions pourtant essentielles puisque basées sur le comportement attendu du système : quels tests mettre en place pour telle user-story ? Où et comment rédiger la documentation ? Qu’est-ce que j’attends de ma fonctionnalité ? 

Origines

Codifié en 2003, quelques mois seulement après que Kent Beck eu finalisé son concept de TDD, le Bevahior Driven Development (ou BDD) de Dan North est avant tout un concept qui complète le TDD et non qui cherche à le remplacer. En se basant sur le fait que de nombreux développeurs se trouvaient désemparés face à l’écriture des tests, le BDD implique de se poser les bonnes questions en amont du projet et notamment de déterminer quels types de tests doivent être exécutés afin de décrire le comportement attendu des fonctionnalités implémentées. 

Autre notion extrêmement importante, celle de transmission de l’information. Lors de la rédaction des différentes caractéristiques du BDD, il est apparu que la compréhension du projet par l’ensemble des parties prenantes était elle aussi problématique. Le BDD implique donc une communication inter-équipes importante avec pour objectif d’enlever toute ou partie de la frustration qu’une incompréhension de certaines parties du projet peut créer. 

Les caractéristiques du BDD

De manière laconique, on peut dire que le Behaviour Driven Development cherche à rendre la  communication plus claire et facile entre les développeurs, les chefs de projet, le product owner et toutes les parties prenantes du projet. Pourquoi ? Car en améliorant la collaboration et la transmission d’information entre ces différents acteurs du projet, ce dernier ne pourra qu’augmenter en termes de qualité : moins de stress, moins de fatigue, plus rapide, etc. 

Pour atteindre l’objectif d’une collaboration réussie, il est nécessaire de prendre en compte trois aspects fondamentaux concernant la transmission des informations. La première est que la communication doit être établie sur la base d’une documentation lisible et compréhensible par tous, c’est notamment le cas pour la création de l’ensemble des tests (cas, classes, résultats). En respectant ce premier, les équipes techniques peuvent aisément communiquer avec le processus marketing et décisionnelle des virages à prendre en fonction du comportement des fonctionnalités. Viennent ensuite les relations avec les testeurs, souvent compliquées lors de l’écriture des tests. 

Le BDD laisse donc la possibilité au PO comme aux testeurs de concevoir eux-mêmes les tests d’acceptation et ainsi d’interagir directement avec les développeurs. Cette partie permet de structurer les différentes parties prenantes techniques autour d’un tronc commun. Enfin, comme il est entendu dans les termes “Behaviour Driven Development”, il vous faut traduire les comportements attendus en des termes compréhensibles par tous en utilisant notamment le langage de Gherkin. 

Le langage de Gherkin se décrit comme suit :  

À chaque début de phrase, il convient de placer les termes Given, When, Then, And selon l’ordre que vous souhaitez implémenter à votre programmation, le tout sans – pour le moment – aucune ligne de code : 

• Etant donné (Given) que je souhaite envoyer une photo de très haute qualité via l’application chat 
   
• Quand (When) la résolution dépasse 16 millions de MPX  
   
• Alors (Then) la photo ne doit pas être envoyé 
   
• Et (And) l’expéditeur reçoit une notification lui informant de l’impossibilité d’envoi. 
   

Cela vous paraît plus logique ? Pourtant, il est une étape souvent oubliée et pourtant aussi importante que celle-ci, la définition du produit de base. Pour ce faire, il suffit de se poser trois autres questions :  

• Who ? Pour qui ? L’utilisateur de l’application de rencontres 
• What ? Quoi ? La possibilité d’envoyer des photos sur l’application 
• Why ? Pourquoi ? Savoir si la personne de l’autre côté du combiné nous plaît 

Exemple

Partir d’un exemple est toujours plus parlant. Imaginons que demain, vous soyez embauché chez un des leaders de la mise en relation d’individus comme Meetic ou Happn. Votre PO vous convoque avec les autres développeurs pour un entretien d’informations visant à vous expliciter l’ensemble des fonctionnalités à implémenter. Serein, vous vous rendez donc dans son bureau où ce dernier vous donne pour seule consigne de réaliser une nouvelle fonctionnalité dans le chat : l’envoi de photos prises par votre téléphone. Vous ressortez du bureau en pensant que cela ne devrait pas être bien compliqué. Pourtant, 1 semaine plus tard, de nombreux problèmes apparaissent lors de vos tests. 

Pourquoi ? Tout simplement parce que de nombreux facteurs de comportements attendus n’ont finalement pas eu lieu, car on ne vous a pas donné assez d’informations.  

Afin d’être complet, il aurait fallu que vous vous renseignez sur les différentes caractéristiques de cette fonctionnalité :  

• Quelle taille maximum la photo peut-elle faire ? 

• Peut-on prendre une photo directement avant l’envoi ou faut-il aller la chercher dans la médiathèque de son GSM ? 
• Quel format de photo peut fonctionner : JPEG, PNG ?  
• Les images animées (GIF) fonctionnent-elles ? 
•  Si j’envoie plusieurs photos en même temps, est-ce que ce sera trop lourd ? 
• Faut-il avoir un compte certifié pour obtenir cette possibilité d’envoi ? 

• Où sont stockées les photos reçues ? 
• Est-il possible de bloquer un certain type de contenu ? 

Bref, vous l’aurez compris, ce que le chef de projet peut avoir dans la tête au début du projet doit être entièrement expliqué et explicité par écrit afin d’avoir toutes les données en main afin de tester en fonction du comportement attendu et non à l’aveuglette. Pour ça, une solution : la communication !

TDD, DDD et BDD

Des trois approches essentielles de la conception d’un logiciel par le Clean Code : TDD, BDD et DDD, le TDD et le BDD sont les plus indissociables. Cependant, le Clean Code sous-entend que seule la collaboration de ces trois méthodologies peut permettre de parvenir à un résultat véritablement propre.  En sommes, on peut relater du fait que ces trois approches permettent de parcourir les étapes suivantes dans la construction d’un code propre : la conception d’un logiciel scalable et évolutif, le rendu d’un logiciel adapté aux besoins déclinés au préalable et uniquement à ces besoins, une véritable réduction de la dette technique du projet, une documentation et une communication bien meilleure entre équipes techniques et non-techniques. 

Comme on peut régulièrement le répéter, il n’existe finalement pas de différences incroyables entre les trois méthodologies puisqu’elles s’unissent autour d’une même volonté de corrélation entre les différentes phases du projet grâce à une vision plus globale du projet par chacun des acteurs techniques (dev, teach lead, testeurs) et non techniques (marketing, PO, users finaux). Chacune des phases doit être pensée pour le général, à savoir : pour qui je le fait, ce que je dois faire pour y arriver, dans quel but ajouter ces fonctionnalités, etc.

Enfin, ces trois approches se retrouvent dans le sens où elles ne sont finalement que des évolutions les unes des autres avec un langage commun permettant une collaboration complète entre les acteurs du projet et les outils usités. 

Ces évolutions notables entre TDD, BDD et DDD sont décrites par Dan North (créateur du terme BDD) comme étant indissociables d’une volonté de collaboration exacerbée entre les différentes parties prenantes, comme il a pu le préciser   : “Si nous pouvions développer un vocabulaire cohérent pour les analystes, les testeurs, les développeurs et l’entreprise, nous serions en bonne voie d’éliminer une partie de l’ambiguïté et des malentendus qui se produisent lorsque les techniciens parlent aux hommes d’affaires. »