tdd

Présentation de la skill tdd

La skill tdd est un guide ciblé pour pratiquer le développement piloté par les tests avec une boucle stricte red-green-refactor, et non un simple prompt générique du type « écrire quelques tests ». Elle convient surtout aux développeurs qui veulent s’appuyer sur l’IA pour créer des fonctionnalités ou corriger des bugs, tout en gardant des tests centrés sur le comportement via des interfaces publiques plutôt que sur les détails d’implémentation.

À quoi sert tdd

Utilisez tdd for Test Driven Development lorsque vous voulez que le modèle :

• planifie une fonctionnalité en petites tranches verticales
• écrive un seul test en échec à la fois
• n’implémente que le minimum nécessaire pour faire passer le test
• refactore en sécurité une fois au vert
• évite les tests fragiles qui cassent lors de refactorings sans impact fonctionnel

Qui tire le plus de valeur de tdd

La skill tdd est particulièrement adaptée si vous avez déjà :

• une base de code avec des tests exécutables
• une API publique, un endpoint, une commande ou un parcours utilisateur clair à cibler
• la possibilité de modifier à la fois les tests et le code de production
• une préférence pour des tests de style intégration plutôt qu’un usage massif des mocks

Elle est particulièrement utile pour les services backend, les bibliothèques, la logique métier et les flux applicatifs où le comportement peut être exercé via une interface réelle.

Ce qui distingue cette skill tdd

Son principal différenciateur est sa position assumée sur la qualité des tests :

• tester le comportement, pas les internals
• privilégier les tests de style intégration
• ne mocker qu’aux frontières du système
• éviter le « découpage horizontal » où l’on écrit tous les tests d’abord puis tout le code ensuite
• utiliser TDD pour façonner de meilleures interfaces, pas seulement pour augmenter la couverture

En pratique, l’usage de tdd est donc plus discipliné qu’un prompt classique demandant à une IA de « rédiger les tests et l’implémentation ».

Ce qui peut freiner l’adoption

Cette skill est moins pertinente si votre environnement ne permet pas d’exécuter les tests, si votre base de code n’offre pas de points d’entrée publics stables, ou si votre équipe cherche surtout des tests unitaires très orientés snapshots ou très riches en mocks. Elle suppose aussi que vous acceptiez d’avancer par petits incréments plutôt que de générer une fonctionnalité complète d’un seul coup.

Comment utiliser la skill tdd

Installer tdd dans votre environnement de skills

Si vous utilisez le système Skills du repository, un schéma d’installation courant est :

npx skills add mattpocock/skills --skill tdd

Ensuite, invoquez tdd lorsque vous demandez au modèle d’implémenter ou de corriger un comportement en suivant un workflow test-first.

Lire ces fichiers en priorité avant un usage intensif de tdd

Le chemin le plus rapide pour comprendre cette skill est :

1. SKILL.md
2. tests.md
3. mocking.md
4. interface-design.md
5. refactoring.md
6. deep-modules.md

Cet ordre compte. SKILL.md pose la philosophie de fonctionnement, tandis que les fichiers de support expliquent concrètement ce que signifient de « bons tests » et un « bon design ».

Bien comprendre le workflow central attendu par tdd

La skill repose sur une boucle très serrée :

1. choisir un petit comportement
2. écrire un test en échec via une interface publique
3. implémenter le minimum de code pour le faire passer
4. refactorer tout en gardant les tests au vert
5. recommencer avec la plus petite tranche suivante

Si vous demandez toute une fonctionnalité d’un coup, vous perdez l’essentiel de la valeur apportée par tdd.

Partir d’un comportement, pas d’une idée d’implémentation

Entrée forte :

• « Add checkout support for expired cards. Public entrypoint is checkout(cart, paymentMethod). Existing test file is checkout.test.ts. Keep using integration-style tests. »

Entrée faible :

• « Create classes for payment orchestration and add unit tests for each method. »

Le premier prompt donne à la skill une cible comportementale. Le second l’oriente vers des spéculations sur le design interne et vers des tests fragiles.

Donner à la skill l’interface publique et la commande de test

Pour obtenir de bons résultats à l’installation et à l’exécution de tdd, indiquez :

• la fonction, la route, la commande CLI ou l’action UI testée
• l’emplacement des tests
• le runner de test et la commande à exécuter
• les contraintes pertinentes, comme la DB, HTTP ou les services externes
• ce qui peut et ne peut pas être mocké

Modèle de prompt pratique :

Use the tdd skill.

Goal: Add [behavior].
Public interface: [function/route/command].
Test location: [path].
Run tests with: [command].
Boundaries to mock: [external API, clock, filesystem].
Do not mock: [internal modules/classes].
Work in red-green-refactor steps and explain each step briefly.

Utiliser des tranches verticales, pas un découpage horizontal

L’un des enseignements pratiques majeurs du repository est d’éviter d’écrire tous les tests en bloc dès le départ. Un bon usage de tdd ici consiste à :

• choisir un scénario réel
• le faire passer
• laisser ce résultat guider le scénario suivant

Cela réduit les abstractions imaginées trop tôt et produit généralement une meilleure forme d’API.

Privilégier les tests de style intégration avec tdd

Le repository favorise clairement les tests qui exercent de vrais chemins de code via des API publiques. En pratique, cela veut dire :

• appeler des fonctions exportées plutôt que des helpers privés
• tester les route handlers via leur interface prise en charge
• vérifier des résultats observables, pas l’ordre des appels internes
• nommer les tests par capacité, par exemple « user can checkout with valid cart »

Si un refactoring modifie les internals sans changer le comportement, un bon test devrait en général rester au vert.

Ne mocker qu’aux frontières du système

La skill tdd n’est pas anti-mock ; elle est contre le fait de mocker votre propre implémentation. À mocker :

• les passerelles de paiement
• les fournisseurs d’email
• le temps / l’aléatoire
• parfois la base de données ou le filesystem, selon la configuration de test

À ne pas mocker :

• vos propres modules
• les collaborateurs internes
• les méthodes privées
• les wrappers minces que vous contrôlez

À elle seule, cette règle a souvent plus d’impact sur la qualité du résultat que la plupart des ajustements de prompt.

Façonner le code pour le rendre testable avant d’en écrire trop

Les fichiers de support insistent sur un point important : de meilleures interfaces rendent TDD plus facile. Demandez au modèle de privilégier un code qui :

• reçoit ses dépendances au lieu de les créer en interne
• renvoie des résultats au lieu de muter un état caché
• garde une surface publique réduite

Si votre design actuel se prête mal au test, indiquez au modèle de commencer par proposer une interface publique plus petite et plus testable.

Exemple de prompt tdd solide

Use the tdd skill to add password reset token expiry.

Context:
- Node + TypeScript
- Public API: `requestPasswordReset(email)` and `resetPassword(token, newPassword)`
- Tests: `src/auth/password-reset.test.ts`
- Run with: `pnpm test password-reset`
- Mock only email sending and time
- Do not mock repository code or internal services

Please:
1. choose the smallest failing behavior first
2. write integration-style tests through public APIs
3. implement minimum code to pass
4. refactor after green
5. avoid asserting internal call counts unless at an external boundary

Cet exemple fonctionne parce qu’il donne à la skill une cible, une politique de frontière et un vrai chemin d’exécution.

Repérer les principaux signaux de qualité en sortie

Un bon résultat issu de cette guide tdd inclut généralement :

• des tests nommés autour d’un comportement visible par l’utilisateur
• un petit scénario à la fois
• une implémentation minimale à chaque étape
• des notes de refactoring après le vert
• peu ou pas de couplage à la structure privée

Un mauvais résultat inclut généralement :

• beaucoup de mocks pour le code interne
• des assertions sur l’ordre des appels
• d’énormes suites de tests dès la première étape
• des abstractions spéculatives avant qu’un premier comportement ne passe

FAQ sur la skill tdd

Est-ce que tdd est réservé aux toutes nouvelles fonctionnalités ?

Non. La skill tdd est aussi très adaptée aux corrections de bugs. Dans de nombreuses bases de code matures, la meilleure première étape est un test de régression en échec qui reproduit le bug via l’interface publique, puis un correctif minimal, puis un nettoyage.

Cette skill tdd est-elle adaptée aux débutants ?

Oui, à condition de déjà savoir lancer les tests de votre projet. Les recommandations sont tranchées mais simples : tester le comportement, garder des tranches petites et éviter les assertions sur les détails d’implémentation. Les grands débutants auront malgré tout souvent besoin d’aide pour comprendre l’architecture du projet et son outillage de test.

En quoi tdd diffère-t-il d’une simple demande à une IA d’écrire des tests ?

Les prompts ordinaires produisent souvent des tests orientés couverture ou très chargés en mocks. La skill tdd pousse le modèle vers :

• des spécifications comportementales
• des refactorings plus sûrs
• des interfaces plus propres
• des étapes itératives plus petites

Cela change à la fois les tests et le design du code de production.

Quand ne pas utiliser tdd ?

Évitez ou limitez tdd for Test Driven Development lorsque :

• le comportement ne peut pas encore être exercé de manière pertinente
• l’environnement est trop difficile à exécuter pendant les itérations
• vous êtes dans une phase d’exploration jetable
• la tâche est surtout mécanique, comme du renommage ou une mise à jour de dépendances

Vous pourrez revenir à TDD une fois le point d’entrée public plus clair.

Est-ce que tdd impose uniquement des tests d’intégration ?

Pas strictement, mais son biais va vers des tests de style intégration via de vraies interfaces. L’objectif n’est pas d’avoir les plus gros tests possibles ; c’est de tester le comportement à un point d’entrée stable. Des tests petits et ciblés restent tout à fait valables s’ils restent au niveau de l’interface publique et évitent le couplage interne.

Quels langages ou frameworks conviennent à cette skill ?

Les idées sont largement indépendantes du langage. Les exemples penchent vers TypeScript et JavaScript, mais les principes de conception s’appliquent aussi à Python, Java, Go, Ruby et à des écosystèmes comparables dès lors que vous pouvez définir des interfaces publiques claires et des frontières de test nettes.

Comment améliorer la skill tdd

Donner à tdd une première tranche plus petite

Le moyen le plus simple d’améliorer les résultats de tdd consiste à réduire la portée de la première étape. Au lieu de « build user invitations », commencez par « user with valid email can request an invitation ». Des tranches plus petites réduisent l’architecture hallucinée et produisent des tests plus propres.

Fournir des règles explicites sur les frontières

Beaucoup de mauvais résultats viennent d’une politique de mocking floue. Dites clairement au modèle :

• quels systèmes externes peuvent être mockés
• quels modules internes doivent rester réels
• si une base de test est disponible
• si le temps doit être injecté ou figé

Cela aide la skill à rester alignée avec la philosophie du repository.

Demander des noms de tests basés sur l’interface publique

Si vous voulez de meilleurs tests, demandez des noms qui décrivent des résultats :

• bon : user can checkout with valid cart
• moins bon : checkout calls payment service

Cette seule consigne suffit souvent à éviter la dérive vers les détails d’implémentation.

Rendre la boucle red-green-refactor visible

Si la première réponse arrive sous la forme d’un bloc complet d’implémentation, demandez au modèle de la restructurer :

• montrer le premier test en échec
• montrer le code minimal pour passer au vert
• expliquer le refactoring séparément
• s’arrêter après une tranche si nécessaire

La skill tdd fonctionne le mieux quand la boucle est visible, et non simplement sous-entendue.

Améliorer le design quand les tests paraissent maladroits

Si le modèle a du mal à écrire des tests propres, le problème vient souvent du design d’interface, pas de la syntaxe de test. Demandez-lui de réviser en direction de :

• l’injection de dépendances
• des entrées et sorties explicites
• des surfaces publiques plus petites
• moins d’effets de bord

C’est là que interface-design.md et deep-modules.md deviennent particulièrement utiles.

Utiliser le refactoring comme passe qualité distincte

Après quelques tranches au vert, demandez explicitement une revue de refactoring à partir des repères du repository :

• duplication
• méthodes trop longues
• modules superficiels
• feature envy
• primitive obsession

Cela évite que l’usage de tdd s’arrête à « les tests passent » et améliore la maintenabilité sans modifier le comportement.

Corriger tôt les modes d’échec fréquents

Si la qualité baisse, les causes habituelles sont :

• trop de code généré avant le premier test en échec
• des collaborateurs internes trop lourdement mockés
• des tests qui vérifient des détails d’implémentation
• une demande de fonctionnalité trop grosse pour un seul cycle
• une interface publique floue ou qui change à chaque étape

Dans ce cas, repartez de zéro avec un comportement, un point d’entrée, un test en échec.

Utiliser les fichiers du repository comme aides à la décision

Pour de meilleurs résultats, faites correspondre votre problème aux documents de support :

• tests.md lorsque le style de test est faible
• mocking.md lorsque les décisions de frontière sont floues
• interface-design.md lorsque les points d’entrée sont maladroits
• refactoring.md après être passé au vert
• deep-modules.md lorsque la forme de l’API devient trop large

Ce parcours de lecture apporte bien plus que le simple survol de SKILL.md.

Itérer en resserrant les contraintes, pas en répétant le même prompt

Si la première sortie est moyenne, ne vous contentez pas de dire « try again ». Améliorez le tour suivant avec des contraintes concrètes :

• cibler un seul comportement
• préserver l’API publique actuelle
• ne pas mocker les modules internes
• préférer une base de test à des mocks de repository
• s’arrêter après le premier cycle red-green-refactor

Ce type d’itération améliore de façon bien plus fiable la qualité d’un guide tdd qu’une simple demande de davantage de détails.