Press "Enter" to skip to content

TDD, ATDD, BDD et plus

Quelles sont les différences entre TDD, ATDD et BDD ?

Test First

Ecrire le ou les tests avant le code de production testé.

C’est une excellente pratique à plusieurs égards :

  • C’est une manière de s’assurer qu’on a les idées claires sur ce que fera le code de production. Si on n’est pas capable de formuler les tests, comment pourrait-on décrire le comportement attendu et donc écrire le code de production ?
  • En écrivant les tests avant le code de production, on n’est pas influencé par l’implémentation lors de la rédaction des tests.
  • Une fois le code écrit, un test automatique ne sert qu’à vérifier la non-régression. Si on écrit le test avant le code, il sert également à guider l’implémentation. Le test devient deux fois plus utile.

Il faut cependant différencier le Test First du TDD, qui est bien plus exigeant.

TDD (Test Driven Development)

TDD est une approche très stricte où on alterne des micro cycles cas de test en échec/écrire le code minimal qui fait passer le test/refactoring qui ne casse aucun test.

Ce n’est pas restreint aux tests unitaires même si évidemment c’est à ce niveau là qu’on en écrira le plus.

ATDD (Acceptance Test Driven Development)

L’ATDD est souvent la première étape du TDD et du Test First en général, en commençant par un premier cas de test de plutôt haut niveau, qui est un test d’acceptation.

Précisons que ce cas de test est automatisé sinon en général on n’appelle pas ça ATDD.

Specification By Example

Avant de parler de BDD je parlerai de Spécifications Exécutables, également Spec By Example en anglais.

Effectivement c’est de l’ATDD avec un formalisme en langage métier.

Given When Then étant le standard de fait mais il y en a bien d’autres, comme par exemple les tables de décision de FitNesse qui par ailleurs plaisent souvent aux fonctionnels.

BDD (Behavior Driven Development)

Passons enfin au BDD.

La meilleure manière que j’ai trouvé pour l’illustrer c’est de parler de l’atelier d’Example Mapping. Il y a deux grandes manières de l’utiliser.

Il y a un mode qu’on pourrait qualifier de “revue de spec” : le PO débarque avec les cartes de règles déjà faites, il les pose sur la table, on écrit ensemble les cartes d’exemple, on challenge ensemble les règles, éventuellement on les ajuste en mode 3 Amigos. Là, on fait du SpecByExample.

Deuxième option : on arrive avec juste le besoin (la carte racine de la Map) et on se pose la question des Exemples : quand on est dans telle situation, qu’est-ce qu’il devrait logiquement arriver ? Et ainsi de suite, pour chaque exemple de situation, on décide du bon comportement à adopter. Et les cartes de Règles, finalement, elles émergent à partir de ces exemples. Quand on utilise l’Example Mapping comme ça, où les règles émergent des exemples plutôt que d’avoir des exemples qui illustrent des règles déjà fixées, alors là vous faites du BDD — du vrai BDD : Behavior-Driven Development.

Quand les règles émergent des exemples plutôt que d’avoir des exemples qui illustrent des règles déjà fixées, alors là vous faites du BDD — du vrai BDD : Behavior-Driven Development.

On le voit bien, quand on a déjà une spec qu’on veut challenger et automatiser, le format tables de décision de FitNesse est idéal : on veut faire le tour des cas de figure et ne rien rater. Quand par contre on part des comportements, c’est plus logique de décrire un scénario et de décider de ce qu’il fait, avant de continuer avec le scénario suivant jusqu’à avoir découvert l’intégralité du fonctionnel à mettre en place.

Laisser un commentaire

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

Top