Le Développement Dirigé par les Tests repose sur trois lois :
- Vous devez écrire un test qui échoue avant d’écrire votre code lui-même.
- Vous ne devez pas écrire un test plus compliqué que nécessaire.
- Vous ne devez pas écrire plus de code que nécessaire, juste assez pour faire passer le test qui échoue.
Cette approche a de nombreux avantages :
Moins de code
Seul le code nécessaire à valider le test est écrit. Ni plus, ni moins. Et qui dit moins de code, dit également moins de poids, moins de maintenance et moins de dette technique.
Moins de recette
L’approche itérative consistant à valider un premier test, puis un second (en validant que le premier reste au vert), puis un troisième (en validant que les deux précédents restent au vert), fait que l’applicatif livré est à 100% conforme à ce qui est attendu, que l’ajout d’une fonctionnalité n’entraîne pas de régression et que tout le code écrit est utile.
Plus d’agilité
Le Développement Dirigé par les Tests facilite également le travail du Scrum Master, qui va pouvoir s’assurer du bon avancement du développement avec ses développeurs.
Certains utilisent le FizzBuzz comme Kata pour bien démarrer la journée… En voici un exemple, sur du Satie :