tdd

Aperçu du skill tdd

tdd est un skill de Test-Driven Development pour construire des fonctionnalités et corriger des bugs avec la boucle rouge-vert-refactor. Il convient particulièrement aux ingénieurs qui veulent un guide pratique de tdd qui aligne les tests sur le comportement, et non sur l’implémentation. Si vous travaillez dans une base de code où les refactorings sont fréquents, où les interfaces comptent et où des tests fragiles vous ralentissent, ce skill vous aide à écrire des tests qui résistent aux changements.

L’objectif principal est simple : transformer une idée de fonctionnalité encore floue en une suite sûre de petites étapes testables. Le skill tdd est particulièrement utile pour l’automatisation des tests, les tests de type intégration et le code qui gagne à avoir des frontières plus nettes. Son parti pris le plus fort est de tester via les interfaces publiques et de ne simuler que les vraies frontières du système.

À quoi sert tdd

Utilisez tdd lorsque vous voulez un workflow test-first pour un nouveau comportement, une correction de bug ou un refactoring qui doit rester protégé par un filet de sécurité. C’est un bon choix quand vous connaissez déjà le résultat attendu, mais pas encore le chemin d’implémentation le plus propre.

Ce qui différencie ce skill tdd

Le repo ne dit pas seulement « écrivez d’abord les tests ». Il impose une discipline précise : éviter les découpages horizontaux, privilégier les tests centrés sur le comportement et concevoir des interfaces faciles à tester. Cela rend le skill tdd plus utile qu’un prompt générique lorsque vous avez besoin de tests durables plutôt que de tests rapides mais fragiles.

Quand tdd est un mauvais choix

Si vous avez besoin d’un test unitaire ponctuel, d’un script jetable ou d’une vérification des appels internes fortement basée sur des mocks, ce n’est probablement pas le bon outil. Le skill vise des logiciels que vous prévoyez de refactorer, où la qualité des tests compte davantage que leur quantité.

Comment utiliser le skill tdd

Installer et charger le skill

Utilisez la commande d’installation du répertoire pour l’étape tdd install, puis ouvrez d’abord SKILL.md. Ensuite, lisez tests.md, mocking.md, interface-design.md, refactoring.md et deep-modules.md pour connaître les règles qui façonnent réellement la qualité de sortie.

Donnez au skill un comportement, pas une solution

Le meilleur tdd usage commence par un résultat visible par l’utilisateur, une entrée et un résultat attendu. Bonne forme de prompt :

• « Ajouter une validation du checkout pour que les paniers invalides renvoient une erreur claire et que les paniers valides finalisent le paiement »
• « Corriger le bug qui crée deux comptes quand deux e-mails identiques sont utilisés »
• « Écrire des tests pour un flux de retry contre une API de paiement, en utilisant l’interface publique du service »

Mauvaise forme de prompt :

• « Écrire des tests pour le checkout »
• « Rendre ce module plus testable »
• « Mock la base de données et vérifier que la fonction a été appelée »

Suivez la boucle rouge-vert-refactor

Commencez par le plus petit comportement observable, écrivez un seul test qui échoue et le prouve, implémentez le minimum de code pour le faire passer, puis refactorez en gardant le test au vert. N’assemblez pas tous les tests d’abord puis l’implémentation ensuite ; le skill met explicitement en garde contre les découpages horizontaux, parce qu’ils créent un comportement imaginé plutôt qu’un comportement réellement testé.

Lisez d’abord ces fichiers

Pour une exécution pratique, priorisez :

• SKILL.md pour la philosophie et le workflow
• tests.md pour les bons et mauvais patterns de test
• mocking.md pour les mocks limités aux frontières
• interface-design.md pour rendre le code plus facile à tester
• refactoring.md pour savoir quoi améliorer après le premier passage au vert

FAQ sur le skill tdd

tdd sert-il seulement aux tests unitaires ?

Non. Ce skill tdd privilégie les tests de type intégration via les interfaces publiques, ce qui le rend souvent plus adapté à l’automatisation des tests et aux tests de comportement qu’aux approches très centrées sur les tests unitaires isolés.

Dois-je tout mocker ?

Non. Une règle essentielle de ce tdd guide est de ne mocker qu’aux frontières du système, comme les API externes, le temps, l’aléatoire, ou parfois le système de fichiers ou la base de données. Ne mockez pas vos propres modules juste pour faire passer les tests.

Les débutants peuvent-ils utiliser tdd ?

Oui, s’ils savent décrire clairement le comportement attendu. La principale courbe d’apprentissage n’est pas la syntaxe ; c’est le choix de la bonne frontière et l’évitement des tests d’implémentation.

En quoi tdd est-il différent d’un prompt standard ?

Un prompt standard peut produire des tests qui se contentent de compiler. Le skill tdd est plus directif : il pousse vers des tests centrés sur le comportement, des incréments courts et une conception d’interface qui garde les tests stables pendant les refactorings.

Comment améliorer le skill tdd

Commencez avec une entrée plus précise

Vous obtiendrez de meilleurs résultats avec tdd si vous incluez le comportement, la frontière et la contrainte. Par exemple, dites « construire un expéditeur d’e-mails avec retry qui utilise un vrai wrapper de service, mais mock le temps et le fournisseur externe » plutôt que « rendre ce code testable ».

Surveillez les modes d’échec courants

Les erreurs les plus fréquentes sont le sur-mocking, le test de méthodes privées et les tests qui décrivent comment le code fonctionne au lieu de décrire ce que voit l’utilisateur. Si la première version semble trop attachée à l’implémentation, reformulez le prompt en nommant l’API publique et le résultat observable.

Itérez du test vers la conception

Après la première sortie, servez-vous des échecs pour améliorer la conception de l’interface : paramètres plus petits, valeurs de retour plus claires et moins d’effets de bord. Si le code reste difficile à tester, le problème vient peut-être de la forme de l’API, pas des tests.

Demandez des cibles de refactorisation après le passage au vert

Une fois le comportement couvert, demandez au skill d’identifier la duplication, les méthodes trop longues, les modules trop plats, la feature envy ou la primitive obsession. C’est là que le skill tdd apporte une vraie valeur ajoutée : il vous aide à passer de « tests qui passent » à une conception plus propre qui restera facile à tester.