Quelle est la différence entre l’ATDD et la BDD ?

ATDD et BDD - first
ATDD et BDD - first

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. Le format des user-stories ne permet pas de piloter facilement la mise ne place de tests.

Voici un exemple simple :

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)

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é.

Cette pratique 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’ATTD 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

Ces deux pratiques de tests fonctionnels (ATTD et BDD) sont différentes mais sont très proches. Cependant la philosophie autour de la mise en place de ces tests 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 » 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 ?

Mot clés : tdd bdd

Merci à Xavier Pigeon pour un commentaire sur Linkedin qui a permis d’éclairer des erreurs que comportait l’article. Son intervention a amené l’article à être réécris.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 490 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

2 Commentaires

  1. 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.

  2. « 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)}

1 Rétrolien / Ping

  1. Pourquoi il ne faut pas tout tester en fin de sprint ? - Blog Myagile Partner

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.