BDD

Le BDD ou développement piloté par le comportement (Behavior Driven Development) est une évolution naturelle du TDD. En plus de posséder tous les bénéfices de cette dernière, cette pratique a des vertus magiques permettant aux représentants du métier et aux développeurs de se comprendre, de jouer les tests de recettes automatiquement plusieurs fois par jour et empêche la désynchronisation entre le code et les spécifications fonctionnelles.

Qu’est ce que le BDD ?

BDD est une méthode de développement qui encourage la collaboration entre les développeurs et les autres parties prenantes au projet. Bien que les tests unitaires issus de TDD soient très intéressants pour valider la partie technique d’un logiciel (comportement des classes, cohérence des fonctions, tests de valeurs entrées / sorties, …), la méthode souffre de deux problèmes : Ils ne sont lisibles que par des développeurs du fait qu’ils sont écrits en langage informatique. Ils sont très difficiles à mettre en œuvre et à maintenir lorsqu’il s’agit de tester des scénarios fonctionnels complexes. Pour palier ces problématiques, BDD propose d’utiliser des scénarios de tests écrits dans une langue compréhensible par tous. Ces scénarios sont ensuite passés dans un automate qui se charge de générer les tests unitaires associés.

Comment ça marche ?

Tout comme l’approche TDD, aucune ligne de code n’est écrite sans que les tests ne soient rédigés au préalable. Pour cela, BDD apporte un niveau d’abstraction supplémentaire en obligeant les développeurs à écrire des scénarios fonctionnels plutôt que des tests techniques basiques. L’écriture de ces scénarios se fait à l’aide d’un langage textuel avec quelques règles syntaxiques simples appelé le Gherkin Voici par exemple un scénario écrit dans ce langage :

Comment les mettre en œuvre ?

Dans un premier temps, il est nécessaire d’installer un programme spécifique qui permettra de convertir les scénarios en tests unitaires.

A l’heure actuelle, ce type de programme existe pour quasiment tous les langages de programmation évolués. Le BDD peut donc être utilisé sur tous les types de projets.

Pour les développeurs .NET qui utilisent Visual Studio, le plugin de référence pour faire du BDD est SpecFlow.

Une fois le package installé, 3 nouveaux templates deviennent disponibles lorsque vous faites un clic droit -> Ajouter un nouvel élément

Les éléments de type «SpecflowFeature » permettent de créer des scénarios Gherkin directement dans visual studio, et les éléments de type « SpecFlowStepDefinition » donnent la possibilité de définir le code associé à chaque phrase de scénario.

Comme vous l’aurez compris, chaque phrase de scénario étant reliée à une méthode dans le fichier « step », une phrase de scénario peut être utilisée plusieurs fois avec des paramètres variables sans pour autant devoir réécrire le code associé !

Qu’est-ce que ça apporte ?

Tout comme le code de votre application, les scénarios BDD ajoutent de la valeur à votre projet de développement, et ce pour plusieurs raisons :

Ils font office de spécifications fonctionnelles extrêmement détaillées, intégrées directement dans l’environnement de développement. Ils font office de tests de recette, permettant de s’assurer que l’application ne subit pas de régressions fonctionnelles à chaque publication d’une nouvelle version. Ils sont modifiables et adaptable à l’infini sans lignes de code supplémentaires, dès lors que le code écrit dans les fichiers « steps » est implémenté Ils peuvent être réutilisés pour un autre projet annexe, car la majorité des langages évolués permettent d’exploiter les scénarios Gherkin

Une anecdote pour montrer les bienfaits du BDD

Une secrétaire médicale appelle à l’agence pour se plaindre de son logiciel : « Cela fait plusieurs mois que je demande à ce que les feuilles de soins électroniques puissent être envoyés avec une double cotation, les services techniques m’expliquent que le bug a été remonté aux développeurs, mais ce n’est toujours pas corrigé, c’est inacceptable ! On ne peut pas travailler ! »

La personne qui a reçu ce coup de fils s’avère être le patron qui débarque aussi sec dans l’open space : « Je viens de recevoir un coup de fil d’une secrétaire, pourquoi n’avez pas encore implémenté la double cotation dans les FSE ? Il faut le faire au plus vite, car cela devient intolérable ! »

Or, il s’avère que l’équipe qui travaille sur le sujet est en déplacement, et la seule personne à pouvoir intervenir sur le code ne connait pas bien le sujet.

Après avoir jeté un coup d’œil au projet, la modification semble tellement triviale qu’il se demande pourquoi elle n’a pas été faite plus tôt. Le développeur apporte sa modification et relance tous les tests pour valider son implémentation.

Et là, surprise : sur les 8000 tests unitaires, un seul ne passe pas. Son nom : Interdire la double cotation dans les FSE !

En double cliquant sur le test unitaire défectueux, le développeur tombe sur un scénario BDD qui décrit précisément le cas de figure qu’il a modifié. Le scénario semble très clair : il ne faut surtout pas qu’une FSE autorise la double cotation.

Le développeur en parle au patron qui contacte par téléphone l’équipe métier : une discussion très houleuse éclate au téléphone. « Comment ? Vous essayez de forcer la double cotation pour une FSE ? Mais vous voulez aller en prison où quoi ? »

Visiblement, la double cotation est interdite par le cahier des charges sésame vitale. Un cabinet médical qui s’amuse en envoyer des FSE avec ce mode peut se voir redressé par les services de contrôles de l’assurance maladie.

« Mais alors ? Pourquoi la secrétaire médicale veut pouvoir le faire ? » Demande le patron.

« Elle veut le faire car c’est beaucoup plus simple pour elle, et son ancien logiciel ne gérait pas ce cas de figure. Si nous débrayons cette fonctionnalité, la mise à jour sera déployée dans plus de 300 cliniques, et la probabilité pour que l’une d’entre elle se fasse redresser et pointe du doigt notre logiciel est énorme ! »

Imaginez un instant que ce projet ait été géré par des méthodes traditionnelles sans BDD.

Le patron aurait demandé au développeur de faire la modification. Le développeur aurait modifié le code sans que l’équipe métier en soit informée. La mise à jour aurait été déployée sans problème, permettant à des milliers d’utilisateurs de violer une règle métier très importante. Au bout de plusieurs mois (voir année) l’une d’entre elle aurait été contrôlée par l’assurance maladie qui aurait forcément procédé à son redressement (ou à l’arrêt de l’activité de la clinique). La clinique aurait pointé du doigt le logiciel qui a permis de faire cette action illicite. Le scandale serait remonté chez l’éditeur de logiciel qui aurait organisé une chasse aux sorcières en interne.

Qui est responsable du désastre ?

Les experts métiers ? Non, car ils ont correctement décrit dans une spécification que ce cas ne devait jamais arriver.

Le développeur ? Non, car il a suivi les ordres du patron.

Le patron ? Non, car il a répondu au besoin de son client.

Le client ? Non, car le client est roi, et il a toujours raison.

Les tests unitaires générés par le BDD ont donc permis d’empêcher une véritable catastrophe en provoquant une communication entre le développeur, le patron, et les experts métiers.

Conclusion

Le BDD vise à combler le déficit de communication entre les experts du domaine et les développeurs en reliant des spécifications fonctionnelles lisibles à leurs implémentations sous-jacentes.

Grace à ce mécanisme, développeurs et experts métiers sont amenés à communiquer plus souvent pour comprendre le besoin, et les spécifications fonctionnelles sont toujours synchronisées avec le code, évitant ainsi que le logiciel s’éloigne du besoin réel avec le temps.