Le Behaviour-Driven Development (BDD) est une méthode éprouvée. Apparue aux alentours de 2005 cette méthode de développement propose de se baser sur des exemples. Métiers, testeurs et développeurs se mettent autour de la table afin se parler et surtout de se comprendre. Clément Héliou dans un article précédent décrivait très justement le BDD ainsi :

Le BDD est une méthode dite de Knowledge Crunching. Elle s’appuie sur une collaboration forte entre experts métiers, développeurs et testeurs afin d’explorer le domaine du métier et les problèmes que l’on cherche à résoudre. La connaissance et le vocabulaire ainsi partagés sont capturés sous forme d’exemples concrets qui se concentrent sur le comportement de l’application.

Cet article n’a pas vocation à être une énième introduction, il en existe des centaines. Ce ne sera pas non plus une ixième tentative de vous convaincre qu’il n’est pas nécessaire d’automatiser pour faire du BDD !

Je vous propose 5 bonnes raisons de vous mettre au BDD ou, si vous êtes déjà convaincu, 5 arguments pour vous aider à convaincre vos sponsors !

#1 Votre métier va se mettre à valider vos spécifications !

Un scénario Gherkin est très simple à lire par tous et donc à valider. C’est un fait, quand il s’agit de faire valider une spécification, il arrive d’attendre longtemps devant sa boite mail… Mais ne jetons pas la pierre. Qui serait à l’aise et motivé pour valider et donc, endosser la responsabilité d’un document souvent difficile à lire, qui se veut exhaustif et dont on généralise les explications ? Personne !

Lorsque l’on pratique le BDD, après une phase d’exploration vient la phase de reformulation. C’est là que le format Gherkin est utilisé. Cette syntaxe, bien que simple à comprendre, demande un effort intellectuel et un peu d’entraînement pour en maitriser l’écriture. Une fois cet exercice maitrisé, vous ne pourrez plus vous en passer. Un scénario écrit de cette manière est parfois difficile à produire, mais il est extrêmement simple à lire !

#2 Rendre l’algorithmique aux ingénieurs !

Se focaliser sur les exemples permet aux ingénieurs de se réapproprier l’algorithmique. Avez-vous déjà reçu une spécification qui ressemble à un pseudo algorithme ? « Si le montant est inférieur à la somme des paramètres alors le résultat est divisé par 2 mais si un c’est un jour pair alors on fait autrement. » Souvent dans les équipes, un analyste qui se trouve être un ancien développeur prémâche le travail avec sa propre logique. Partant d’un bon sentiment, cette façon de faire peut avoir des conséquences désastreuses. Le développeur se retrouve à traduire en code sans comprendre ce qu’il fait. Ou pire, la spécification est simplement une requête SQL. Déjà vu ?

Avec la pratique du BDD, on coécrit des exemples, des scenarii avec des contextes chiffrés et des résultats souhaités. On laisse donc aux ingénieurs le choix de l’algorithmique et d’une solution cohérente avec la technologie utilisée.

#3 Votre code sera lisible, même par un non dev !

Troisième bonne raison de faire du BDD, écrire du code lisible ! Reformuler avec les techniques du BDD permet de tendre vers un langage universel : le métier et les développeurs utilisent le même vocabulaire. On parle d’ubiquitous language. Ce vocabulaire co-construit sera utile pour que la base de code survive à celui qui l’a codée. 2 ou 3 ans plus tard, le développeur et le représentant du métier seront partis, mais les remplaçants seront capables de lire le code ensemble.

Scénario : Validité d’un ticket de métro "zone 1-2" dans Paris
Etant donné un client qui achète un ticket de métro "zone 1-2"
Quand il passe le portique à Châtelet
Alors le portique laisse passer le client

Si mon titre de scénario est bien clair et précis, le nom de mon test sera évident, on évite le test1() venant d’un manque d’inspiration

Si ma clause 'Quand' est bien formulée, le nom de ma méthode est facile à trouver, on évite les calculer() ou les toto() pour un nom de méthode parlant : PasserLePortique(Ticket t, Station s)

#4 Pour la première fois votre documentation sera à jour !

Pratiquer le BDD, c’est la promesse d’avoir une documentation fonctionnelle à jour durant toute la vie de l’application. Une documentation écrite par une personne n’est et ne sera jamais à jour, c’est impossible. La référence, c’est le code. Une documentation écrite n’est qu’une tentative d’expliquer le code.

Pour avoir une documentation à jour, il faut donc qu’elle soit générée. A chaque build, une nouvelle version de la documentation décrit ce que le code fait. Arriver à une documentation de qualité demande du travail et un changement de comportement. La documentation devient une priorité, on se préoccupe de son rendu. Elle peut être traditionnelle. Un document pdf avec un sommaire et des parties distinctes ou plus moderne avec un moteur de recherche par #tag.

Pickles – Serenity BDD

#5 Vous pourrez enfin recruter les bonnes personnes !

Le BDD vous permet de toucher un panel de développeurs beaucoup plus large! C’est en discutant récemment avec un manager que j’ai compris ce point qui parait de la plus haute importance. En effet, ce manager me racontait qu’il avait changé sa façon de recruter depuis que l’équipe pratiquait le BDD. Dans son milieu, la finance, il avait pris l’habitude de recruter des développeurs avec des compétences métier. Le but était d’améliorer les échanges avec le métier et les utilisateurs. Depuis, il n’y a plus besoin de se limiter aux profils spécialistes : le nombre de candidats envisageables augmentent. Il peut concentrer ses recherches sur les candidats maitrisant le TDD et le software craftsmanship en général. Les profils finances étant encore plus rares, c’est économiquement intéressant. C’est une autre façon de définir le découplage d’une feature team (cf. cet article sur les responsabilités d’une feature team).

Conclusion

The three amigos (l’atelier de co-écriture entre PO, testeurs et développeur en BDD)

Je pratique le BDD depuis maintenant 8 ans. J’ai découvert cette méthode en cherchant justement un moyen de mieux collaborer avec l’autre partie de mon équipe qui était localisée à Singapour. Il m’est difficilement concevable de ne pas appliquer les principes du BDD en 2020 mais je vois toujours des personnes qui découvrent ou qui peinent à convaincre leurs métiers de se lancer. J’espère que ces 5 effets permettront de vous remettre en selle. Et pour les plus aguerris, je vous recommande ces quelques liens pour approfondir davantage le sujet.