Après 5 ans de pratique quotidienne du BDD, force est de constater que certaines idées reçues ont la vie dure. Cependant, quatre ont particulièrement retenu mon attention dans le sens où celles-ci montrent une profonde méconnaissance du sujet.

It's time to debunk!

"On utilise le BDD comme méthode de test."

C'est celle qui ressort le plus souvent. Et elle est aussi fausse que fréquente !
Pour comprendre pourquoi, un bref rappel de ce qu'est le BDD s'impose.

Très simplement, il s'agit d'une méthodologie dont le but est de s'assurer que l'ensemble des parties prenantes du développement logiciel partagent la même compréhension du comportement logiciel attendu.
Pour cela, Product Owner (PO), Quality Assurance (QA), et développeurs (les 3 amigos) se mettent autour de la table afin de poser par l'exemple la manière dont le logiciel doit se comporter.

C'est tout ! Il n'est pas question de tests ici mais bien de discussions. Cette confusion vient du fait que bien souvent, l'objectif secondaire de cette pratique est l'implémentation de tests automatisés répondant aux exigences des exemples écrits en session.

"Nous faisons du BDD : nous utilisons Cucumber et Gherkin !"

Tout d'abord, il faut comprendre que Cucumber et Gherkin ne sont pas la même chose.

Gherkin est un Domain-Specific Language (DSL). Grossièrement, c'est un cadre à l'écriture des exemples que l'on appellera alors scénarios.

Il en existe d'autres, et une équipe pourrait même décider d'utiliser son propre DSL.
On réservera l'écriture d'un DSL sur mesure à des équipes plus matures sur l'exercice ou avec des contraintes très spécifiques auxquelles Gherkin ne répondrait pas.
Gherkin étant un DSL largement utilisé et prêt à l'emploi, il facilite l'adoption de la méthode. Répondant à la plupart des besoins et étant majoritairement supporté par les outils d'automatisation de tests, il est souvent privilégié.

Parmi les outils d'automatisation de test, nous retrouvons Cucumber. Cucumber exploite les scénarios écrits en Gherkin afin de permettre l'automatisation de tests. Il repose donc sur Gherkin.

Bien que ces deux outils aient été conçus pour aider et capitaliser sur la pratique du BDD, leur utilisation seule ne suffit pas à dire qu'une équipe en a adopté la méthode. Il est nécessaire de comprendre que le BDD est avant tout une discussion. Gherkin n'est qu'une aide à l'écriture d'exemple. En utilisant un DSL, l'équipe s'accorde sur l'anatomie des exemples et peut alors observer, à travers le même prisme, le comportement logiciel attendu.

La force du BDD vient des discussions que la méthode provoque et non des outils utilisés par la suite. Il faut voir l'automatisation de tests basés sur les exemples comme la cerise sur le gâteau.
Une équipe utilisant Cucumber sans les discussions qui définissent le BDD écrira ses tests en Gherkin par contrainte de l'outil et non par respect de la méthode.

Faire du BDD c'est discuter, et non coder.

"On n’a pas besoin de tous les devs, le techlead suffit !"

Nous venons de voir que le but même de la méthode est d’arriver à une compréhension commune du comportement attendu. Mettre à l’écart une partie de l’équipe rentre donc en conflit avec la philosophie du BDD.

Mais pourquoi est-ce dangereux de mettre les développeurs à l'écart de la réflexion ?

Un développeur implémente le besoin tel qu'il le comprend. Et il y a autant de manières de comprendre un besoin qu'il y a de personnes dans l'équipe. C'est pour cela que l'on utilise l'exemple. C'est une manière efficace d'illustrer un besoin mais aussi de co-construire son ubiquitous language. On réduit ainsi les incertitudes et les incompréhensions en regardant tous dans la même direction : vers les exemples.

Tout est une histoire de point de vue

Il est important de retenir que ce qui part en production est ce que les développeurs ont compris du besoin et non ce qui est écrit dans un ticket. Nous avons donc besoin de comprendre le métier pour l'implémenter afin d’en limiter les interprétations erronées.
Par conséquent, limiter l'exercice à un seul développeur compromet les bénéfices apportés par le BDD.

Notons cependant qu'il n'est pas indispensable que tous les développeurs soient présents lors de l'exercice. La réalité du terrain fait qu'il peut être fréquent d'avoir 1 ou 2 personnes absentes. Cela ne doit pas empêcher un projet/produit d'avancer.
En revanche, l'absence du PO est beaucoup plus problématique. Les séances ne doivent pas se dérouler sans lui, sous peine de perdre de vue certains aspects clés du besoin.

"On a essayé, c'est trop compliqué !"

La frustration liée à la mise en place

Le BDD n'est pas compliqué. En revanche, la méthode peut s'avérer frustrante pour une équipe qui s'y essaye pour la première fois. Les discussions provoquées amènent généralement beaucoup de remise en question sur la connaissance actuelle du logiciel. Décortiquer son comportement nécessite un vocabulaire précis et contextualisé souvent manquant au démarrage.

La marche est alors haute pour rattraper le retard et les discussions tournent dans un premier temps souvent autour du vocabulaire à utiliser.

Dans une mission où je suis intervenu, aucune méthode n'était vraiment mise en place. Nous avons alors appliqué le BDD au domaine de prix qui était à la fois critique et souvent sujet à problèmes. Lors des premières séances, aucun scénario n'a été produit. En revanche, les discussions ont amené l'équipe à enrichir le vocabulaire. Là où seul le mot "prix" était utilisé sont apparues des notions bien plus précises comme "prix barré", "prix remisé", "prix avant", "prix en baisse", etc. La compréhension des besoins et les discussions se sont fluidifiés, la précision des développements améliorée.

Pour faciliter cette étape, vous pouvez très bien utiliser des ateliers comme l'event storming qui permettra de se familiariser plus rapidement avec les mots clés du métier. Cet atelier, qui a pour objectif d’identifier évènements métiers et acteurs clés du logiciel, possède une très bonne synergie avec le BDD.

Une méthode non comprise

Une autre raison qui peut faire échouer l'adoption de la méthode est... de ne pas réellement l'adopter. Nous avons vu que certaines équipes pensaient faire du BDD car leur tests reposent sur Cucumber (et qu'ils devaient donc être écrits en Gherkin).
Sans tout le travail en amont, ces scénarios rédigés lors de la phase de développement n'apportent rien de ce que la méthode ambitionne.

La méthode n'étant pas comprise, le jugement de sa complexité est alors basé sur des éléments qui ne lui sont pas propres.

To BDD or not to BDD ?

En tant que pratiquant de la méthode depuis maintenant 5 ans, je ne peux que recommander son utilisation. Les leviers sont énormes. La fluidification de la communication, l'appropriation du métier par l'ensemble de l'équipe, la précision des développements et j'en passe, sont autant de bénéfices qui me font croire aujourd'hui que cette pratique devrait davantage être exploitée.

En revanche, sa méconnaissance et les imprécisions dans sa mise en œuvre sont, à mon avis, encore un frein à son adoption.

C'est pour cela, qu'Ippon a construit Level up craft, une offre de coaching autour du Software Craftsmanship dont le BDD fait partie.