La méthode TDD (Test-Driven Development) est une approche du développement basée sur l’écriture de tests avant le code de production. Cette méthode comporte de multiples cycles de trois phases :
- RED : Écriture d’un test unitaire qui échoue. Ce test doit vérifier une fonctionnalité ou un comportement spécifique du code.
- GREEN : Écriture du code minimal nécessaire pour faire passer le test. L’objectif est de rendre le test opérationnel sans ajouter de fonctionnalités supplémentaires.
- REFACTOR : Amélioration du code pour le rendre :
- Compréhensible : rendre le code plus facile à lire et à comprendre.
- Optimisé : améliorer la rapidité ou la consommation de ressources.
- Flexible : adaptable aux changements futurs.
- Maintenable : plus facile à entretenir et à corriger.
- Réutilisable : peut être utilisé dans d’autres parties du projet.
- Évolutif : être capable de s’adapter à de nouvelles exigences.
Les 4 lois du TDD :
- Ne pas écrire un code de production tant qu’un test unitaire d’échec n’a pas été écrit. Principe même du test first.
- Écrire uniquement le test unitaire suffisant pour échouer.
- Écrire uniquement le code de production suffisant pour rendre opérationnel le test d’échec courant ;
- Remanier le code de production pour l’améliorer tout en conservant les fonctionnalités existantes.
Je vois dans cette méthode une meilleure qualité finale. En nous concentrant sur le résultat par petites étapes en découpant le problème global. En ajoutant les tests, nous avons une boucle de feedback qui nous garantit de ne pas introduire de régressions. Nous gagnons ainsi du temps en évitant les erreurs sur les fonctionnalités déjà codées.
Et puis, personne ne viendra nous dire : “Nous n’avons plus le temps, il faut livrer immédiatement, nous ferons les tests plus tard.”, en sachant que ce “plus tard” ne viendra quasiment jamais.
Source :