Pour commencer, il existe deux termes relativement proches dans le monde des tests automatisés qui sont revenus sur le devant de la scène avec le mouvement Devops et Software Craftsmanship : l’ATDD et la BDD (behavior driven development).
Article : Le manifeste du Software Craftsmanship
Des scénarios fonctionnels automatisés (BDD)
La BDD (behavior driven development) est un type de tests fonctionnels automatisés écrit avec un langage naturel compris de tous appelé Gherkin ; ce sont les Product Owner (ou représentant métiers) qui font ce travail.
N’étant pas simple pour automatiser des tests, le BDD privilégie le given-when-then au format classique des user-stories. En effet, le format des user-stories ne permet pas de piloter facilement la mise ne place de tests.
Par exemple :
Etant donné que je suis un client sur une fiche produit Quand je rajoute un produit d'identifiant "2345" au panier Et que ce produit a un stock a "5" Alors le produit se rajoute au panier
Je l ‘ai écrit en français mais tous les outils de tests automatisés de tests ne reconnaissent pas forcément le français.
Ensuite un outil va transformer ce test fonctionnel écrit en langage naturel souvent mis dans un fichier .feature pour en faire des fonctions de code vides à remplir par les développeurs.
L’auteur de cette approche, pour faire simple, pensait que les tests réalisés avec la TDD n’étaient pas suffisant pour obtenir une qualité optimale et assurer à 100% de la non régression future. Etant une extension de la TDD, la BDD recommande aux développeurs d’écrire le test avant d’écrire le code associé.
Rappel du cycle de la TDD :
-
- Ecrire le test unitaire
-
- Lancer celui-ci et vérifier qu’il échoue (classe pas encore codée)
-
- Ecrire la classe à tester avec le minimum pour faire marcher le test
-
- Lancer le test et vérifier qu’il fonctionne
-
- Finir le code complet de la classe
- Vérifier que le test fonctionne toujours (non-régression)
Voici un article pour aller plus loin sur le sujet des tests fonctionnels :
Article : Et si on faisait de la BDD (Behavior Driven Development)
D’ailleurs, vous pouvez regarder la vidéo de la minute agile qui parle aussi de ce sujet :
Pour l’ATDD, il est possible d’écrire le test en utilisant le même langage naturel en amont mais cela n’est pas obligatoire. Le développeur peut écrire directement le code du test fonctionnel sans passer par la case « langage naturel ».
L’idée principale des deux pratiques ATDD et BDD
L’ATDD (Acceptance Test-Driven Development) a pour vocation d’écrire les tests fonctionnels avant même de coder la fonctionnalité ; ce sont les tests fonctionnels qui vont guider à la création technique de la fonctionnalité.
Ainsi, cette pratique ATDD se rapproche fortement de la TDD (Test-Driven Development) qui a pour but elle d’écrire les tests unitaires (des incréments).
L’ ATDD propose un cycle de travail aux développeurs très proche de celui que l’on a en TDD avec l’ajout de la présence du client :
- Définir le test avec le client
- Ecrire le test fonctionnel
- Lancer celui-ci et vérifier qu’il échoue (fonctionnalité pas encore codée)
- Ecrire la fonctionnalité à tester avec le minimum pour faire marcher le test
- Lancer le test et vérifier qu’il fonctionne
- Finir le code complet de la fonctionnalité
- Vérifier que le test fonctionne toujours (non-régression)
La BDD (Behavior Driven Development) présente une pratique qui propose au Product Owner (ou représentant du client) d’écrire les tests fonctionnels afin d’indiquer aux développeurs les comportements attendus.
En effet, l’idée est d’enlever toute incompréhension entre les métiers (ou représentants) et les développeurs ; ce n’est pas seulement dans le seul but d’écrire un test.
L’ATDD et la BDD sont deux pratiques similaires
Si l’ATDD est une technique d’ingénierie logicielle malgré la présence du client pour la définition du test, la BDD propose que les comportements soient pilotés dès l’écriture des demandes pour aider l’équipe technique dans les attendus métiers.
Ce sont des pratiquent très similaires en réalité. Cependant la philosophie diffère sur le moment de la définition des tests.
Conclusion BDD et ATDD
En conclusion, ces deux pratiques de tests fonctionnels (ATDD et BDD) sont différentes mais sont très proches. Cependant la philosophie autour de la mise en place de ces tests (ATDD et BDD) est différente.
C’est la raison d’ailleurs du terme « Behavior » qui parle de comportement (qui pilote les demandes jusqu’à leur réalisation) et « Acceptance Test » (AT de ATDD) qui parle plus de l’implementation d’un test d’acceptance où le client vient prêter assistance à l’équipe technique pour l’implementation.
Faites-vous ce type de tests au sein de vos structures (BDD/ATTD) ?
Mot clés : tdd bdd
Lien utile lié à l’ATDD : What is the difference between ATDD and BDD?
D’ailleurs, merci à Xavier Pigeon pour son aide à l’écriture de l’article : ATDD et BDD.
D’un point de vue test, je compléterais ton argumentation par l’aspect couverture de test pour préciser que les tests automatisés via le BDD + « Gherkin outillé » couvriront le Q2 pour des tests fonctionnels (ne s’interdisant pas d’utiliser BDD pour du non fonctionnel, alors couvert en Q4) et que ceux conçus via l’ATDD couvriront eux le Q3, complétés par du test exploratoire.
« La BDD (behavior driven development) est un type de tests fonctionnels automatisés »
C’est une méthode de développement, qui s’appuie sur l’automatisation des tests et qui est susceptible de mettre en oeuvre des formes de test différentes.
BDD != {tests (fonctionnels ou non)}