Le développement piloté par les tests (TDD) a été introduit au chapitre : on écrit le test avant le code. Voici comment le cycle se déroule vraiment.

Le cycle rouge - vert - refactor

1. Rouge : on écrit un petit test pour un comportement qui n'existe pas encore. On le lance : il échoue (rouge). C'est normal — le code n'est pas écrit.
2. Vert : on écrit le minimum de code pour que le test passe (vert). Pas plus.
3. Refactor : maintenant que le comportement est protégé par un test, on nettoie le code (le rendre lisible, enlever les répétitions) en vérifiant que le test reste vert.

Puis on recommence pour le comportement suivant. Chaque cycle dure quelques minutes.

Pourquoi écrire le test d'abord

• Cela oblige à définir précisément ce que le code doit faire avant de l'écrire.
• On obtient une suite de tests automatiques qui vérifie tout, à chaque modification future.
• On ne code que ce qui est nécessaire pour passer les tests : moins de code inutile.

L'objection courante

« Ça prend plus de temps. » C'est vrai à l'écriture immédiate, faux sur la durée : le temps gagné à ne pas chasser des bugs et à modifier le code sans peur dépasse largement le surcoût initial.

Ce que le TDD ne garantit pas

Que la fonctionnalité répond au vrai besoin. Le TDD vérifie que le code fait ce qu'on a dit ; c'est le rôle du PO et des critères d'acceptation de s'assurer qu'on a dit la bonne chose.

Exemple concret : pour la règle « 1 point par euro dépensé », l'équipe de fidélité écrit d'abord un test : « un achat de 25 € crédite 25 points ». Il échoue. Elle écrit le calcul. Il passe. Elle ajoute un test pour les centimes, puis pour un montant nul. Chaque règle est protégée avant d'exister.

À vous de jouer : décrivez les trois étapes du cycle TDD dans l'ordre.