Développement piloté par les tests (TDD)
Langue de sortie
Par défaut, communiquer en français (simplifié) avec l'utilisateur, et rédiger les stratégies de test, les descriptions de tests et les résumés d'implémentation en français. Si l'utilisateur spécifie explicitement une autre langue ou si la documentation existante en impose une autre, suivre cette convention. Le code, les commandes, les noms de produits et les citations qui doivent rester dans leur langue d'origine ne sont pas traduits.
Philosophie
Principe fondamental : Les tests doivent vérifier le comportement via les interfaces publiques, pas les détails d'implémentation. Le code peut changer complètement ; les tests ne devraient pas.
Les bons tests sont de style intégration : ils exercent des chemins de code réels via les API publiques. Ils décrivent ce que le système fait, pas comment il le fait. Un bon test se lit comme une spécification – « l'utilisateur peut finaliser une commande avec un panier valide » vous dit exactement quelle capacité existe. Ces tests survivent aux refactorisations car ils ne se soucient pas de la structure interne.
Les mauvais tests sont couplés à l'implémentation. Ils simulent des collaborateurs internes, testent des méthodes privées, ou vérifient via des moyens externes (comme interroger directement une base de données au lieu d'utiliser l'interface). Le signe d'alerte : votre test échoue quand vous refactorisez, mais le comportement n'a pas changé. Si vous renommez une fonction interne et que les tests échouent, ces tests testaient l'implémentation, pas le comportement.
Voir tests.md pour des exemples et mocking.md pour les directives de simulation.
Anti-patron : Tranches horizontales
N'ÉCRIVEZ PAS tous les tests d'abord, puis toute l'implémentation. C'est ce qu'on appelle la « découpe horizontale » – traiter ROUGE comme « écrire tous les tests » et VERT comme « écrire tout le code ».
Cela produit des tests médiocres :
- Les tests écrits en lot testent un comportement imaginé, pas un comportement réel
- Vous finissez par tester la forme des choses (structures de données, signatures de fonctions) plutôt que le comportement orienté utilisateur
- Les tests deviennent insensibles aux changements réels – ils passent quand le comportement casse, échouent quand le comportement est correct
- Vous dépassez vos phares, en vous engageant dans une structure de test avant de comprendre l'implémentation
Approche correcte : Tranches verticales via des balles traçantes. Un test → une implémentation → répéter. Chaque test répond à ce que vous avez appris du cycle précédent. Parce que vous venez d'écrire le code, vous savez exactement quel comportement compte et comment le vérifier.
MAUVAIS (horizontal) :
ROUGE : test1, test2, test3, test4, test5
VERT : impl1, impl2, impl3, impl4, impl5
BON (vertical) :
ROUGE→VERT : test1→impl1
ROUGE→VERT : test2→impl2
ROUGE→VERT : test3→impl3
...
Workflow
1. Planification
En explorant la base de code, lisez CONTEXT.md (s'il existe) pour que les noms de tests et le vocabulaire de l'interface correspondent au langage du domaine du projet, et respectez les ADR dans la zone que vous touchez.
Avant d'écrire du code :
- Confirmer avec l'utilisateur quels changements d'interface sont nécessaires
- Confirmer avec l'utilisateur quels comportements tester (prioriser)
- Identifier les opportunités de modules profonds en utilisant les principes de conception de base de code lorsque les limites de l'interface ne sont pas claires. N'invoquez pas une autre compétence automatiquement à moins que l'utilisateur ne le demande explicitement.
- Lister les comportements à tester (pas les étapes d'implémentation)
- Obtenir l'approbation de l'utilisateur sur le plan
Demandez : « À quoi devrait ressembler l'interface publique ? Quels comportements sont les plus importants à tester ? »
Vous ne pouvez pas tout tester. Confirmez avec l'utilisateur exactement quels comportements comptent le plus. Concentrez l'effort de test sur les chemins critiques et la logique complexe, pas sur tous les cas limites possibles.
2. Balle traçante
Écrivez UN test qui confirme UNE chose à propos du système :
ROUGE : Écrire le test pour le premier comportement → le test échoue
VERT : Écrire le code minimal pour passer → le test réussit
C'est votre balle traçante – prouve que le chemin fonctionne de bout en bout.
3. Boucle incrémentale
Pour chaque comportement restant :
ROUGE : Écrire le test suivant → échoue
VERT : Code minimal pour passer → réussit
Règles :
- Un test à la fois
- Seulement assez de code pour passer le test actuel
- Ne pas anticiper les tests futurs
- Garder les tests concentrés sur le comportement observable
4. Refactorisation
Une fois tous les tests passés, recherchez des candidats à la refactorisation :
- Extraire les duplications
- Approfondir les modules (déplacer la complexité derrière des interfaces simples)
- Appliquer les principes SOLID là où c'est naturel
- Considérer ce que le nouveau code révèle sur le code existant
- Exécuter les tests après chaque étape de refactorisation
Ne refactorisez jamais en ROUGE. Passez d'abord au VERT.
Checklist par cycle
[ ] Le test décrit le comportement, pas l'implémentation
[ ] Le test utilise uniquement l'interface publique
[ ] Le test survivrait à une refactorisation interne
[ ] Le code est minimal pour ce test
[ ] Aucune fonctionnalité spéculative ajoutée