test-driven-development

Présentation de la compétence test-driven-development

Ce que fait réellement la compétence test-driven-development

La compétence test-driven-development impose à un agent IA un workflow TDD strict pour les nouvelles fonctionnalités, les corrections de bugs et les changements de comportement : écrire d’abord un test, vérifier qu’il échoue pour la bonne raison, écrire le minimum de code de production pour le faire passer, puis refactorer en sécurité. Sa vraie valeur n’est pas simplement « écrire aussi des tests », mais d’imposer un ordre de travail où l’implémentation est pilotée par un comportement exécutable.

À qui la compétence test-driven-development convient le mieux

Cette test-driven-development skill convient particulièrement aux développeurs qui utilisent l’IA sur de vrais dépôts, là où la justesse compte : fonctionnalités applicatives, logique de service, corrections de bugs, refactoring et prévention des régressions. Elle est particulièrement utile si vous voulez empêcher le modèle de foncer directement dans l’implémentation et lui faire produire des étapes plus petites, vérifiables et faciles à relire.

Le vrai besoin auquel elle répond

La plupart des utilisateurs installent test-driven-development parce que les prompts de code génériques ont tendance à produire le code d’abord, puis à greffer des tests ensuite. Cette compétence change ce comportement. Elle aide à obtenir une implémentation ancrée dans des tests d’abord rouges, ce qui rend l’agent plus simple à relire et moins enclin à inventer des comportements non vérifiés.

Ce qui la distingue d’un prompt générique du type « écris des tests »

L’élément différenciant, c’est la « loi d’airain » de la compétence : aucun code de production sans test en échec au préalable. C’est bien plus strict qu’un prompt ordinaire. La compétence insiste aussi sur le fait de vérifier que l’échec initial est le bon échec, et pas simplement n’importe quel rouge, ce qui constitue un garde-fou très concret que beaucoup de résumés superficiels du TDD oublient.

Limites importantes à connaître avant l’installation

Il s’agit d’une compétence de processus, pas d’une boîte à outils de test liée à un framework précis. Elle ne choisira pas à votre place toute votre architecture de test et ne fournit ni scripts utilitaires ni documentation riche au-delà de SKILL.md et testing-anti-patterns.md. Si vous avez besoin d’un accompagnement poussé sur Jest, Pytest, JUnit ou Playwright, cette compétence sert mieux de couche de workflow que de guide de test complet.

Comment utiliser la compétence test-driven-development

Installer la compétence test-driven-development

Installez-la depuis le dépôt avec :

npx skills add https://github.com/obra/superpowers --skill test-driven-development

Si votre environnement prend en charge la découverte locale des compétences, vérifiez que la compétence apparaît bien sous le nom test-driven-development et qu’elle est accessible à l’agent avant de commencer le travail sur une fonctionnalité.

Commencez par lire ces fichiers

Pour ce flux d’installation de test-driven-development et d’utilisation, commencez par :

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

Lisez d’abord SKILL.md pour comprendre le workflow et ses contraintes. Lisez ensuite testing-anti-patterns.md si votre tâche implique des mocks, de l’isolation, des tests UI, ou toute tentation d’ajouter au code de production des points d’entrée destinés uniquement aux tests.

Connaître le minimum d’entrées dont la compétence a besoin

La compétence fonctionne le mieux si vous fournissez :

• la fonctionnalité, le bug ou le changement de comportement
• les fichiers concernés ou les limites du module
• le framework de test déjà utilisé dans le dépôt
• le comportement attendu, visible côté utilisateur ou côté système
• les contraintes d’API, de rétrocompatibilité ou de performance

Sans ce contexte, l’agent peut quand même appliquer le TDD de manière mécanique, mais il risque de choisir le mauvais niveau de test ou de produire des tests maladroits, davantage adaptés à l’outil qu’au codebase.

Transformer une demande vague en prompt prêt pour le TDD

Prompt faible :

Add support for password reset.

Prompt plus solide :

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

La version la plus solide donne à l’agent assez de contexte pour choisir le bon test initial et respecter le cycle rouge-vert-refactor.

Utiliser la compétence test-driven-development comme un workflow par étapes, pas comme une génération en bloc

Un schéma d’utilisation de test-driven-development efficace en pratique :

1. Demandez uniquement le premier test en échec.
2. Vérifiez si l’échec cible bien le comportement visé.
3. Demandez l’implémentation minimale pour le faire passer.
4. Ne demandez le refactoring qu’une fois le vert obtenu.
5. Répétez pour la petite tranche de comportement suivante.

Cette approche produit de meilleurs résultats que de demander toute la fonctionnalité d’un seul coup, car la compétence est conçue autour de petits incréments validés.

Vérifier correctement la phase « rouge »

Un point essentiel de ce guide test-driven-development : un test qui échoue ne suffit pas à lui seul. L’échec doit prouver que le test vise bien le comportement manquant. Si le test échoue à cause d’erreurs d’import, de fixtures cassées ou d’un setup sans rapport, le cycle n’a pas réellement commencé.

Dans votre prompt, demandez explicitement à l’agent d’expliquer pourquoi le test échoue et pourquoi cet échec est le bon.

Choisir le bon premier test

Le meilleur premier test cible en général le plus petit changement de comportement qui ait un sens vu de l’extérieur. Bons candidats :

• la reproduction d’un bug
• une règle métier précise
• un changement de réponse d’endpoint
• le comportement d’une méthode métier
• une interaction UI avec un impact utilisateur clair

Mauvais points de départ :

• de gros scénarios end-to-end
• une couverture snapshot trop large
• des tests qui figent trop tôt l’implémentation interne

Appliquer les conseils anti-patterns dès que des mocks apparaissent

Le fichier d’appui testing-anti-patterns.md devient important si l’agent commence à abuser des mocks. La compétence met fortement en garde contre le fait de tester le comportement des mocks au lieu du comportement réel. C’est particulièrement pertinent pour test-driven-development for Test Automation, où les agents IA ont souvent tendance à créer des assertions sur des placeholders mockés parce qu’elles sont plus faciles à satisfaire que de vrais résultats.

Si un test vérifie qu’un mock s’est affiché, qu’un mock a été appelé d’une manière triviale, ou qu’il a fallu ajouter une méthode réservée aux tests dans le code de production, arrêtez-vous et redéfinissez le périmètre du test.

Demander à l’agent de respecter la loi d’airain

Si le modèle a déjà commencé à rédiger l’implémentation, la consigne de la compétence est stricte : supprimer le code de production et repartir d’un test en échec. En pratique, inutile d’en faire une scène, mais vous devriez demander explicitement à l’agent d’ignorer l’implémentation spéculative précédente et de régénérer la solution à partir d’une séquence test-first.

Formulation utile :

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

Adapter la compétence test-driven-development à la stack de test de votre dépôt

La compétence est centrée sur le processus ; vous devez donc l’ancrer dans votre stack :

• pytest pour les services Python
• Jest ou Vitest pour la logique JS/TS
• RSpec pour Ruby
• JUnit pour Java
• Playwright ou équivalent seulement quand le comportement relève vraiment du niveau navigateur

Si votre dépôt suit déjà une pyramide de tests solide, indiquez à l’agent où ce changement doit se situer. Sinon, le modèle risque de partir sur le style de test le plus visible au lieu du plus économique et utile.

Exemple de prompt pour un vrai travail sur dépôt

Un bon prompt de test-driven-development skill ressemble à ceci :

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

Ce prompt donne le comportement, l’emplacement, le framework et les critères de revue.

FAQ sur la compétence test-driven-development

Est-ce que test-driven-development vaut la peine d’être installé si je connais déjà le TDD ?

Oui, si votre principal problème est d’amener les agents IA à suivre réellement le TDD plutôt qu’à simplement en parler. La test-driven-development skill est utile moins comme support pédagogique que comme contrainte comportementale pour le modèle.

Est-ce adapté aux débutants ?

Globalement oui. Le workflow est simple et explicite. La partie la plus difficile pour un débutant consiste à choisir le bon premier test et le bon niveau de test. Si vous débutez en tests, utilisez d’abord cette compétence sur de petites corrections de bugs plutôt que sur de larges nouvelles fonctionnalités.

Dans quels cas test-driven-development est-il peu adapté ?

C’est un moins bon choix pour des prototypes jetables, du code généré ou de simples modifications de configuration, sauf si le risque d’erreur est élevé et que votre relecteur humain veut malgré tout une discipline test-first. Les consignes source présentent explicitement ces cas comme des exceptions à discuter avec un partenaire humain.

En quoi est-ce différent d’un prompt ordinaire ?

Les prompts ordinaires disent souvent « implémente X et ajoute des tests ». Cette compétence change l’ordre du travail et traite cet ordre comme non négociable. C’est précisément cette séquence qui fait la valeur de l’outil, car elle réduit les implémentations hallucinées et améliore la relisibilité.

Cette compétence couvre-t-elle aussi le setup des frameworks ?

Pas en profondeur. L’installation de test-driven-development est simple, mais la compétence elle-même ne fournit pas une documentation étendue de configuration spécifique à chaque framework. Elle suppose que vous pouvez orienter l’agent vers votre stack de test existante ou vers les conventions de votre dépôt.

Puis-je utiliser test-driven-development pour du refactoring ?

Oui. C’est un bon choix pour le refactoring quand le comportement doit rester stable. Le schéma pratique consiste d’abord à verrouiller le comportement actuel avec des tests, puis à refactorer en laissant les tests verts vous protéger.

Est-ce pertinent pour les tests UI et end-to-end ?

Parfois, mais avec prudence. Pour le travail UI, le fichier sur les anti-patterns est particulièrement important, car l’IA peut dériver vers des assertions sur la présence de mocks ou des artefacts d’implémentation. Commencez par le plus petit comportement utilisateur réel que vous puissiez vérifier.

Comment améliorer la compétence test-driven-development

Donnez du comportement attendu, pas des idées de solution

Pour obtenir une meilleure utilisation de test-driven-development, décrivez le comportement attendu et les contraintes au lieu de dicter l’implémentation. Le TDD fonctionne mieux quand le test définit les résultats et que le code émerge de ces vérifications.

Meilleure entrée :
Users should see an error when uploading files over 10MB.

Moins bonne entrée :
Add a fileSizeValidator class and call it from the controller.

La première laisse de la place à une implémentation minimale plus propre.

Précisez le niveau de test attendu

Beaucoup de mauvais résultats viennent d’un mauvais périmètre de test. Dites à l’agent si vous voulez :

• une logique métier au niveau unitaire
• une intégration autour d’un service ou d’une API
• un comportement au niveau navigateur

Ce seul choix a souvent plus d’impact que n’importe quel autre détail du prompt.

Forcez des incréments plus petits

Un mode d’échec fréquent consiste à demander trop de choses dans un seul cycle. Si le modèle écrit une suite de tests large et une grosse implémentation d’un seul bloc, recadrez :

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

Cela permet de garder la boucle test-driven-development intacte.

Exigez une explication sur la validité du premier test

Demandez à l’agent de justifier :

• pourquoi ce test est la plus petite tranche utile
• quel échec exact est attendu
• pourquoi cet échec prouve que le comportement est absent

Cela améliore la qualité, car les hypothèses cachées remontent avant même le début de l’implémentation.

Repérez tôt les anti-patterns

Les baisses de qualité les plus fréquentes sont :

• tester des mocks au lieu du comportement
• introduire dans le code de production des méthodes réservées aux tests
• écrire d’abord des tests qui passent puis appeler cela du TDD
• choisir des assertions liées aux détails d’implémentation
• sauter l’étape de refactoring une fois le vert obtenu

Si vous en voyez un, arrêtez le cycle et demandez un premier test corrigé au lieu de bricoler autour du problème.

Donnez explicitement les conventions du dépôt

La compétence fonctionne mieux quand vous précisez :

• les conventions de nommage des tests
• l’emplacement des tests
• les patterns de fixtures
• la politique sur les mocks
• le style d’assertion préféré

Comme le dépôt ne fournit qu’un support léger, ces conventions locales améliorent concrètement la qualité du résultat.

Itérez après le premier résultat

Après le premier rendu, ne vous contentez pas de demander « plus ». Posez des questions ciblées :

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

C’est le levier le plus puissant en pratique pour améliorer la test-driven-development skill : garder l’agent dans la boucle plutôt que le laisser sauter les étapes.

Associez-la au jugement humain pour les exceptions

La compétence est volontairement stricte. C’est une force, mais elle peut être appliquée à l’excès. Si la tâche n’est qu’un changement de configuration, une mise à jour de code généré ou un prototype jetable, posez la question du coût réel d’un TDD complet. Les meilleurs résultats viennent d’un usage de la compétence là où la séquence test-first améliore la qualité des décisions, et pas simplement là où elle peut être appliquée.