Développement Piloté par les Tests (TDD)
Écrivez d'abord le test qui échoue. Regardez-le échouer. Écrivez le code minimal pour le réussir. Refactorez. Un test qui réussit immédiatement ne prouve rien — vous ne l'avez jamais vu attraper un bug.
Loi de fer : Pas de code de production sans un test qui échoue d'abord. Si vous avez écrit du code avant le test, supprimez-le et recommencez. « Garder comme référence » est un test après coup déguisé — supprimer signifie supprimer.
Quand l'utiliser
- Implémenter toute nouvelle fonctionnalité ou comportement
- Corriger un bug (reproduisez-le d'abord avec un test — le Pattern Preuve)
- Refactoriser ou modifier un comportement existant
- Déclenché par "tdd", "test-driven", "red green refactor", "测试驱动开发", "红绿重构", "测试驱动"
Pas pour : générer des tests pour du code déjà écrit (utilisez test-generation) ;
prototypes jetables ou configuration pure (implémentez directement).
Exceptions (confirmer avec l'utilisateur) : prototypes jetables, code généré, modifications de configuration pure sans impact comportemental.
Étapes
0. Découvrir d'abord la stack
Le cycle est universel ; les commandes ne le sont pas. Avant le premier test, trouvez comment
ce dépôt teste : lisez package.json / pyproject.toml / Cargo.toml /
pom.xml / go.mod, vérifiez l'existence de ./gradlew, Makefile, les workflows CI, et
la nomenclature des fichiers de test existants. Ne supposez jamais npm test — utilisez la commande propre au dépôt
pour chaque ROUGE, VERT, et vérification finale.
1. ROUGE — écrire un test qui échoue
Un comportement, un test, une tranche verticale (balle traceuse qui répond à ce que le dernier cycle vous a appris). Écrivez le test que vous souhaiteriez exister — il décrit l'API souhaitée, pas l'implémentation. Nommez-le comme une spécification ("rejette l'email vide", pas "test1").
Convenez de la couture (interface publique testée) avant d'écrire. Aucun test à une couture non confirmée — convenir des coutures en amont concentre l'effort de test sur les chemins critiques aut lieu de chaque cas limite. Utilisez du code réel plutôt que des simulacres ; si vous devez doubler une dépendance, utilisez le double le plus simple qui fonctionne (Réel > Faux > Stub > Simulacre — voir références/stratégie-test.md). Les simulacres isolent les frontières, pas la chose testée.
2. Vérifier ROUGE — regarder échouer
Exécutez la commande de test ciblée. Confirmez :
- Il échoue (pas d'erreurs — les erreurs signifient corriger la configuration et réexécuter)
- Il échoue pour la bonne raison (fonctionnalité manquante, pas une faute de frappe)
- Un test qui réussit immédiatement signifie que vous testez un comportement existant — corrigez le test
3. VERT — écrire le code minimal
Le code le plus simple qui réussit le test. Aucune fonctionnalité spéculative, aucune
"flexibilité", aucun refactoring de code adjacent. YAGNI. N'ajoutez pas de méthodes réservées aux tests
(destroy(), reset()) dans les classes de production — placez le nettoyage dans les utilitaires de test.
4. Vérifier VERT — regarder réussir
Exécutez la commande de test ciblée, puis la suite complète. Confirmez :
- Le nouveau test réussit
- Aucun autre test n'est cassé (si c'est le cas, corrigez maintenant — ne sautez pas)
- La sortie est impeccable (pas d'avertissements, pas de tests ignorés)
5. REFACTORISER — nettoyer
Seulement quand c'est vert : extrayez des helpers, améliorez les noms, supprimez la duplication. Exécutez les tests après chaque étape de refactoring. N'ajoutez pas de comportement. Le refactoring appartient à l'étape de revue, pas au cycle d'implémentation rouge → vert.
6. Commit
Commitez le test et l'implémentation ensemble comme une seule tranche verticale. Puis commencez le prochain test qui échoue.
Corrections de bugs — le Pattern Preuve
Ne commencez pas par corriger. Écrivez un test qui reproduit le bug (ROUGE confirme qu'il existe), puis corrigez (VERT prouve que la correction fonctionne). Le test reste comme une garde anti-régression. Ne corrigez jamais un bug sans un test de reproduction.
Vérifier
- Chaque nouveau comportement a un test qui a d'abord échoué
- La suite complète réussit avec la commande de test propre au dépôt
- Les corrections de bugs incluent un test de reproduction qui échouait avant la correction
- Les noms de tests décrivent le comportement, pas l'implémentation
- Aucun test ignoré ou désactivé ; aucune méthode réservée aux tests dans le code de production
Références
- ${CLAUDE_PLUGIN_ROOT}/references/engineering-principles.md — discipline partagée par toutes les compétences
- references/test-strategy.md — pyramide de tests, hiérarchie des doubles de test (Réel > Faux > Stub > Simulacre), DAMP plutôt que DRY
- references/testing-anti-patterns.md — mauvais usage des simulacres, méthodes réservées aux tests, simulacres partiels, fonctions de barrière
- references/mocking.md — quand utiliser des simulacres, conception pour la simulabilité
- references/good-tests.md — exemples de bons et mauvais tests, tests tautologiques
Traduit et adapté pour les développeurs francophones.