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

Ecrit par << Paquet Judicaël >>

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.

Article : Le manifeste du Software Craftsmanship

Des scénarios fonctionnels automatisés

La BDD est un type de tests fonctionnels automatisés écrit avec un langage naturel compris de tous appelé Gherkin ; en général ce sont les Product Owner (ou représentant métiers) qui font ce travail. 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.

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 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 :

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

Dans la BDD, il n’y a pas d’obligation d’écrire le test avant de créer les fonctionnalités contrairement à la pratique d’ATDD.

L’ATDD et la BDD différents mais complémentaires

En effet, en mélangeant ces deux pratiques, certaines équipes y trouveront un excellent moyen de proposer un produit proche des attentes clients tout en bénéficiant d’une baisse des regressions dans le futur.

Voici le cycle quand on mélange les deux pratiques :

  1. le Product Owner écrira le test fonctionnel en Gherkin
  2. l’outil convertira ce test en fonction de code vide à remplir
  3. le développeur développera le test fonctionnel
  4. le développeur développera la fonctionnalité
  5. le test sera automatisé

Conclusion

Ces deux pratiques de tests fonctionnels sont différentes mais peuvent être vraiment complémentaires. Faites-vous ce type de tests au sein de vos structures ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

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