Développement piloté par les tests.
Une discipline de développement dans laquelle on écrit un test qui échoue avant le code qui le fait passer, puis on refactorise — en laissant les tests guider la conception au fil de cycles courts et resserrés.
##Intent
Piloter la conception et vérifier l'exactitude du code en écrivant un test qui échoue pour chaque petit morceau de comportement avant d'écrire le code qui le satisfait, puis en améliorant la conception tandis que les tests vous protègent.
##Problem
Le code écrit sans tests est risqué à modifier : il n'existe aucun moyen rapide de savoir si une modification a cassé quelque chose. Les tests écrits après coup tendent à être superficiels, façonnés pour s'adapter à un code parfois déjà difficile à tester, et ils influencent rarement la conception.
Sans force contraignante, les conceptions tendent aussi à devenir enchevêtrées et difficiles à exercer de façon isolée.
##Solution
Travaillez selon un court cycle Rouge-Vert-Refactorisation :
- Rouge — écrivez un petit test pour le prochain morceau de comportement et regardez-le échouer.
- Vert — écrivez le code le plus simple qui fait passer le test, même s'il est laid.
- Refactorisation — nettoyez le code (et les tests) maintenant qu'ils sont au vert, la suite protégeant contre les régressions.
Répétez par boucles de quelques minutes. Comme les tests viennent en premier, le code est testable par construction et la suite documente le comportement attendu.
##Structure
- Le cycle — Rouge → Vert → Refactorisation, répété continuellement.
- Liste de tests — la liste évolutive des comportements encore à couvrir.
- Arrange–Act–Assert — la forme d'un test unitaire ciblé.
- Unité testée — la petite tranche de comportement que chaque test fige.
##Applicability
- Utilisez-le pour du code comportant une véritable logique et des branchements, ainsi que pour du code pérenne qui évoluera souvent.
- Particulièrement précieux là où une boucle de rétroaction rapide et la sécurité face aux régressions comptent.
- Moins adapté aux prototypes jetables (spikes) ou au travail exploratoire d'interface où la conception est encore mouvante.
##How to Implement
- Choisissez le prochain petit comportement de votre liste de tests.
- Écrivez un test qui le vérifie, puis exécutez la suite pour le voir échouer (rouge).
- Écrivez le minimum de code nécessaire pour passer ; exécutez la suite (vert).
- Refactorisez le code de production et le code de test tout en gardant la suite au vert.
- Répétez, en ajoutant des comportements à la liste à mesure que vous les découvrez.
##Pros & Cons
- Une couverture de test élevée comme sous-produit, et non comme une réflexion après coup.
- Une rétroaction rapide détecte les régressions en quelques secondes.
- Encourage des conceptions découplées et testables.
- La suite tient lieu de documentation vivante et exécutable.
- Rythme initial plus lent, et une réelle courbe d'apprentissage.
- Peut trop insister sur les unités isolées tout en passant à côté de lacunes d'intégration.
- Les tests sont aussi du code — ils doivent être maintenus et refactorisés.
- Ne remplace pas les tests exploratoires, d'intégration ou de bout en bout.
