Introduction
Le BDD, pour Behavior Driven Development (et non la Base De Données), traduit par « développement piloté par le comportement » est une méthode qui encourage la collaboration entre les équipes fonctionnelles, techniques et autres participants non-techniques dans le cadre d’un projet informatique.
Cette approche peut se faire de manière collective favorisant ainsi les échanges entre les différentes entités grâce à un langage naturel qui permet aux personnes métiers de se faire mieux comprendre et aux développeurs de réaliser les besoins exprimés.
C’est une pratique que Dan North a formalisé en 2003 comme une extension au Test Driven Development. Si le TDD n’est écrit que pour et par les développeurs, le BDD, quant à lui, écrit des scénarios d’utilisation qui décrivent le comportement attendu du système afin que tous les participants aient le même niveau de compréhension des fonctionnalités sans avoir à connaitre comment elles seront développées.
A travers cet article, nous allons découvrir :
- Les étapes à suivre pour mettre en pratique la BDD
- Le langage Gherkin
- La différence entre le BDD et le TDD
Les étapes de la BDD
La pratique de la BDD pourrait se résumer par 4 phases distinctes :
1.Définition des besoins
Pour savoir ce qu’il faut développer, une étape primordiale que notamment les responsables fonctionnels font habituellement est de recueillir les besoins du client, ce qu’il attend du projet à élaborer.
2. Les 3 Amigos
Puis se fait ce qu’on appelle techniquement les « 3 amigos ». C’est un atelier réunissant les entités techniques et fonctionnelles notamment le PO, les développeurs, les testeurs, les supports, les commerciaux etc …
Cette réunion a pour but de discuter et de soulever toutes les questions sur le fonctionnement réel de l’application, d’identifier tous les différents comportements couvrant l’attente du client et les décrire en différents scénarios d’utilisation.
3.Transformation des scénarios en tests
Tout le monde a bien compris ce que le client voudrait. Chaque cas d’utilisation a été illustré en différents scénarios. Au tour des responsables de tests, idéalement des testeurs dédiés mais dans certains cas, des développeurs les prennent en charge aussi, d’écrire les tests maintenant. Les différents scénarios vont être les bases pour mettre en place les tests.
Le meilleur moyen de bien écrire ses tests est de suivre le cycle « Red–Green–Refactor » ou « Rouge-Vert-Refactor » en Français. Ce processus est un guide dans l’écriture des tests à partir des scénarios et dont les règles sont les suivantes :
- Rouge : Ecrire un test qui échoue
- Vert : Ecrire un test qui réussit
- Refactor : Factoriser le maximum de codes possible
Nombreux sont les outils technologiques qui permettent de mettre en place concrètement les tests automatisés à partir des scénarios comme Cypress, Specflow ou Playwright …Vous pouvez consulter notre article sur SpecFlow ici.
4.Développement
Grâce aux précédentes étapes, les développeurs sont sûrs de comprendre les règles métier, qui sont parfois vues comme abstraites. Ainsi, les développeurs peuvent commencer leur travail.
Une meilleure compréhension des attentes du client garantit de belles lignes de codes et ainsi moins de bugs.
Pour résumer donc, avec l’approche de la BDD, ce sont les tests écrits en amont qui guident les développeurs dans leurs implémentations afin de garantir une adéquation maximale aux besoins.
Langage Gherkin
Nous avons vu précédemment les 3 amigos, c’est un atelier de spécification où se réunissent les PO, développeurs et testeurs pour écrire ensemble les fonctionnalités en différents scénarios sans détailler comment ceux-ci sont intégrés. C’est un atelier auquel toute personne business ou technique peut participer. Et c’est grâce au langage Gherkin que cela peut se faire.
Le langage Gherkin est un langage simple et naturel, contenant des phrases utilisées dans le quotidien, des phrases compréhensibles par tous.
Gherkin offre des syntaxes simples à utiliser et à mettre avant chaque étape de description :
Ces mots-clés sont en Anglais, mais pour que tout le monde puisse bien comprendre et parler le même langage, Gherkin met à disposition ces mots-clés en différentes langues. Voyons un exemple de traduction pour les 2 langages suivants :
Comme exemple, prenons une fonctionnalité très simple avec 2 scénarios :
Fonctionnalité : Menu du site SoftFluent (https://www.softfluent.fr/ )
Prérequis : Je suis sur la page d’accueil du site
Premier scénario : Ouvrir la page Blog depuis le menu
Je suis sur la page d’accueil de Softfluent.
Quand je clique, sur le menu « Blog », je suis redirigée vers la page des blogs
Et j’ai bien les quatre catégories affichées.
Deuxième scénario : Ouvrir la page Expertises depuis le menu
Je suis la page d’accueil de Softfluent.
Quand je clique sur le menu « Expertises », je suis redirigée vers la page des expertises
Et que le titre « Conseil et Expertise logicielle » est bien affichée.
Voici à quoi ressemble le fichier que nous allons appeler Menu.feature :
BDD vs TDD
Comme vu plus tôt, le BDD est une extension du TDD dont le but est toujours d’écrire les tests avant de passer au développement des fonctionnalités.
Avec le TDD, les développeurs écrivent des lignes de codes pour des tests de fonction par fonction. Evidemment, il faut avoir des compétences techniques pour pouvoir comprendre ce qui ont été écrit.
Cependant, le BDD vise à ce que tout le monde comprenne le fonctionnement réel de l’application grâce aux différents cas d’utilisation décrits en scénarios. Mais un scénario peut être un enchainement de plusieurs fonctions.
Ce sera plus concret avec un exemple. Testons la connexion d’un utilisateur.
Voici comment nous pouvons illustrer le test BDD de celle-ci :
En revanche, pour la même fonctionnalité, les tests TDD consistent à vérifier chacune des fonctions définissant chaque étape pour pouvoir connecter l’utilisateur :
Par ailleurs les tests BDD sont des tests de bout en bout (« E2E »), majoritairement réalisés au niveau de la couche de présentation du système applicatif à tester.
Conclusion
Théoriquement, les étapes de l’approche BDD ne sont pas très compliquées à suivre et à mettre en place. Elle permet de réduire les différents problèmes applicatifs et de se rapprocher de ce que le client attend. Cependant, elle n’est pas encore très appliquée dans la plupart des équipes informatiques actuelles alors que c’est une approche très efficace lors ce qu’il s’agit de réaliser des tests automatisés UI.
