Halte aux idées reçues. Bien que le terme BDD figure dans une bonne partie des offres d’emplois, des CVs et des pratiques d’équipe de développement, la méthode reste largement incomprise et mal utilisée. Souvent assimilé à une pratique de test, le BDD peut vous faire perdre beaucoup de temps, d’argent et d’énergie en l’utilisant de la sorte. Le Behaviour-Driven Development est avant tout un moyen de favoriser la collaboration au sein de l’équipe produit. Faisons le point sur cette pratique.
Un grand nombre d’équipes ou de DSI pensent bien faire en implémentant des “tests” BDD (Behaviour-Driven Development). Ce qui semble être une bonne approche au départ vire souvent au gouffre financier. Comme tout autre outil, le Behaviour-Driven Development peut améliorer le quotidien de votre équipe s’il est bien utilisé ou tourner au cauchemar dans le cas contraire.
Si vous n’êtes pas convaincu par le fait que le BDD n’est pas une approche de test vous pouvez toujours jeter un oeil aux tweets de Daniel Terhorst-North (aussi connu sous le nom de Dan North) développeur logiciel, coach agile et Technologist à l’origine de l’approche BDD, ainsi qu’à deux articles de blog de chez cucumber bdd is not test automation et SpecFlow Why is BDD one of the most misunderstood concepts?
LA PETITE HISTOIRE DU BDD
Le terme Behaviour-Driven Development a été initié en 2003 par Dan North comme un moyen d’enseigner le TDD (Test-Driven Development ou développements pilotés par les tests) aux développeurs, les poussant ainsi à penser le TDD comme une pratique de conception et non une pratique de test. Dan North trouvait le mot “comportement” (Behavior) plus approprié que “test” et utilise dès lors le terme BDD pour parler de cette approche spécifique. Dans la foulée, il crée l’outil JBehave pour se substituer à JUnit, ainsi que tout le vocabulaire et les références liées aux tests.
À la même période, Eric Evans introduit dans son best-seller Domain-Driven Design la notion de langage omniprésent (Ubiquitous Language). Un langage basé sur le domaine métier et partagé entre les développeurs et les utilisateurs.
Dan North et Chris Matt (collègues Business Analyst de Dan) se mettent à imaginer un vocabulaire commun capable de réunir les Business Analysts, les testeurs, les développeurs et les représentants du métier. Dès lors, le BDD passe à une approche qui vise à améliorer la communication en éliminant les ambiguïtés entre les différents intervenants (techniques et non techniques) tout en se focalisant sur la valeur apportée par chaque comportement du logiciel.
LES TROIS PHASES DU BDD
Concrètement, l’approche BDD consiste à comprendre et à valider les exigences métiers au moyen d’exemples illustratifs. Elle se décline en 3 étapes Découverte, Documentation et Automatisation
DÉCOUVERTE
L’étape de découverte est la plus importante de l’approche BDD. Il s’agit de discuter du comportement d’une fonctionnalité et de débusquer tous les critères d’acceptation et les cas limites. La discussion se fait entre les célèbres “trios d’amis” (Three amigos) à savoir les développeurs, le Product owner et le testeur. Rien ne vous empêche d’inviter d’autres personnes susceptibles de vous aider à comprendre un comportement du logiciel. Vous pouvez aussi vous aider d’ateliers d’exemple mapping.
DOCUMENTATION
La deuxième étape consiste à documenter les discussions de la phase de découverte, avec un langage et des scénarios précis. Le document résultant doit être lisible et compréhensible par toute l’équipe ainsi que par les parties prenantes métiers. Dès lors que cette documentation est validée par les trois amis elle devient la source unique de vérité, la référence.
La plupart des outils d’automatisation des scénarios BDD utilisent la syntaxe Gherkin qui permet d’écrire des scénarios de test compréhensibles par des individus non techniques :
Un exemple d’application :
AUTOMATISATION
Dans cette troisième étape, on va utiliser des tests pour créer un lien entre nos scénarios et le code de production. Créant ainsi une documentation “vivante” qui vérifie le comportement du système en temps réel. En d’autres termes, si la modification d’une partie du code modifie un comportement du logiciel, votre outil d’automatisation vous remontera un feedback.
Vous trouvez que ça ressemble beaucoup aux tests de non-régression ? Ce protocole qui permet de valider que la mise en ligne d’une nouvelle fonctionnalité n’impactera pas les fonctions déjà existantes. Vous avez raison, mais cela n’est qu’un effet de bord positif de l’automatisation de vos scénarios BDD. En automatisant un scénario, vous allez sûrement tester le comportement nominal spécifié, mais vous ne pouvez pas tester tous les états possibles du système comme peut le faire un test automatisé ou manuel. Un bon scénario n’est pas forcément synonyme d’un bon test.
Le principal avantage de l’automatisation c’est d’avoir une documentation “vivante” en langage naturel qui reflète le comportement réel de votre application.
Documentation “vivante” generée par SpecFlow+ LivingDoc Generator
PAR OÙ COMMENCER ?
L’essence du BDD est d’éliminer l’ambiguïté entre les parties prenantes et d’éviter le rework. En appliquant les deux premières étapes, vous êtes déjà à un niveau de pratique permettant une compréhension partagée et d’éviter de faire perdre du temps aux équipes.
L’automatisation vient par la suite greffer le résultat de vos discussions au code de production. Résultat : vous disposez d’une documentation lisible dont la pertinence est garantie tout au long de la durée de vie du produit.
Si vous souhaitez mettre en place une démarche BDD dans votre équipe ou entreprise, démarrez toujours par les deux premières étapes et attendez de gagner en maturité pour passer à l’étape d’automatisation.
LES PIÈGES QUI PEUVENT VOUS COÛTER CHER
1 – Faire sauter la première étape
Dans le processus de développement logiciel, la matière première avec laquelle on travaille est l’information. Sauf qu’on oublie souvent que les sources et destinataires de ces informations sont des êtres humains. Par conséquent, chaque intervenant regarde le monde à travers son expérience, son vécu et son prisme métier.
« Ceci n’est pas une pipe », mais un tableau de René Magritte
2 – Faire du Development Driven Behaviour
Une erreur classique que font les développeurs est d’influencer l’écriture des scénarios pour correspondre au code déjà écrit sur d’autres scénarios. Si le fait de réutiliser le code est une bonne pratique, le faire au détriment de la lisibilité des scénarios est toujours une mauvaise idée.
Rappelez-vous que le document écrit doit être lisible et compréhensible par tous les intervenants métiers. Écrire et automatiser des scénarios qui font plaisir à votre code au lieu de décrire le comportement métier de votre système est une pure perte de temps, d’énergie et d’argent.
Une documentation “vivante” est compréhensible par tous le monde
3 – Utiliser les outils d’automatisation des scénarios pour faire du test E2E
Le fait d’utiliser les outils d’automatisation des scénarios BDD tels que Cucumber ou SpecFlow pour rédiger et automatiser des tests revient à tuer une mouche avec un canon.
Pire, on finit par écrire des tests maladroits, verbeux et qui créent un faux sentiment de confiance.Seuls, Cucumber et SpecFlow ne peuvent pas lancer des tests E2E, souvent ils utilisent des d’autres outils spécialement conçus pour implémenter et lancer des tests de bout en bout. Si votre objectif est d’automatiser vos tests de non-régression E2E, utilisez directement les outils de test comme Cypress ou Sélénium sans perdre votre temps à utiliser un intermédiaire inutile pour atteindre votre objectif d’assurer la non-régression de vos applications.
Pourquoi faire simple quand on peut faire compliqué ?
4 – Écrire des scénarios sous une forme impérative
Vos scénarios doivent décrire le comportement prévu du système, et non sa mise en œuvre. En d’autres termes, ils doivent décrire le quoi et non le comment.
Contre-exemple (formulation impérative)
Bon exemple (formulation déclarative) :
3 – Ne pas choisir le bon niveau de test
L’automatisation des scénarios BDD passe par l’utilisation de tests, mais quel niveau de test utiliser (unitaire, intégration, end-to-end) ?
Les bénéfices et inconvénients de chaque type de test restent les mêmes, plus on monte dans la pyramide de test, plus on se rapproche du parcours d’exécution que déclenche la requête de l’utilisateur final. Cela dit, plus on monte dans la pyramide, plus les tests deviennent fragiles, coûteux à écrire, et longs à exécuter.
Pour automatiser les scénarios BDD, il n’y a pas de recommandation particulière, tout dépend de votre contexte. Néanmoins, réfléchissez à 2 fois avant de partir sur une automatisation basée sur des tests d’intégration ou E2E. L’addition peut vite devenir très salée lorsque vous atteignez un certain nombre de scénarios.