test-driven-development

Vue d’ensemble

Ce que fait cette compétence

La compétence test-driven-development encode un workflow de Test-Driven Development (TDD) strict : vous écrivez toujours un test en échec avant tout code de production, puis vous suivez une boucle Red-Green-Refactor disciplinée.

Au lieu d’un vague « écrire des tests à un moment donné », cette compétence impose des règles fermes :

• Aucun code de production sans un test en échec au préalable
• Toujours vérifier que le test échoue pour la bonne raison
• N’écrire que le code minimal nécessaire pour faire passer les tests
• Refactoriser une fois que tout est au vert

Elle renvoie également vers un guide dédié testing-anti-patterns qui vous aide à éviter les tests fragiles ou trompeurs.

Pour qui ?

Utilisez la compétence test-driven-development si vous êtes :

• Un développeur qui veut un workflow fiable pour les fonctionnalités, les correctifs de bugs et les refactorings
• Une équipe qui se standardise sur le TDD et a besoin de règles claires que tout le monde peut suivre
• Un coach ou tech lead qui veut ancrer des habitudes d’automatisation de tests cohérentes

Elle est particulièrement utile sur des bases de code JavaScript et TypeScript, mais les principes s’appliquent à n’importe quel langage et framework de tests.

Problèmes que cette compétence résout

Cette compétence est conçue pour résoudre des problèmes fréquents du développement au quotidien :

• Écrire le code d’abord et ajouter les tests plus tard, voire jamais
• Ne pas savoir clairement si les tests vérifient réellement le comportement
• Craindre de refactoriser parce que les tests sont faibles ou absents
• Surutiliser ou mal utiliser les mocks, au point de tester du faux comportement plutôt que du comportement réel

En suivant le workflow test-driven-development, vous :

• Obtenez un feedback rapide grâce aux tests en échec
• Gardez une trace claire du comportement attendu
• Rendez les refactorings plus sûrs car le comportement est verrouillé par les tests
• Évitez les tests fragiles qui ne vérifient que des mocks ou des détails d’implémentation

Quand l’utiliser (et quand ne pas l’utiliser)

La compétence en amont recommande explicitement d’utiliser le TDD pour :

• Les nouvelles fonctionnalités
• Les correctifs de bugs
• Le travail de refactoring
• Tout changement de comportement

Et elle mentionne des exceptions à traiter avec un partenaire humain, par exemple :

• Prototypes jetables
• Code généré
• Fichiers de configuration

Si vous êtes simplement en « exploration » ou en train de bricoler un spike rapide que vous comptez jeter, cette compétence test-driven-development stricte peut être plus lourde que nécessaire. En revanche, pour des fonctionnalités de production, elle est pensée comme le workflow par défaut, pas comme une option facultative.

Comment l’utiliser

Installation

Pour installer la compétence test-driven-development depuis le dépôt obra/superpowers, exécutez :

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

Cette commande ajoute la définition de la compétence test-driven-development et les fichiers associés à votre environnement Agent Skills. Une fois installée, vous pouvez ouvrir les fichiers de la compétence pour consulter les règles détaillées et les exemples d’anti‑patterns.

Les fichiers clés référencés par cette compétence incluent :

• SKILL.md – les règles TDD principales, dont l’Iron Law et Red-Green-Refactor
• testing-anti-patterns.md – un guide ciblé sur ce qu’il ne faut pas faire dans les tests

Principe central : l’Iron Law

Au cœur de cette compétence se trouve ce que la source appelle l’Iron Law :

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Concrètement :

• Si vous avez écrit du code de production avant un test, vous supprimez ce code et vous recommencez
• Vous ne le conservez pas comme « référence » et vous ne l’adaptez pas pendant que vous écrivez les tests
• Vous ne jetez pas un œil au code supprimé lorsque vous le réimplémentez à partir des tests

Cette règle stricte garantit que chaque ligne de code de production est pilotée par un test réel.

Workflow TDD pas à pas

Une fois la compétence test-driven-development installée, utilisez‑la comme votre workflow par défaut :

1. Écrire un test en échec (RED)

• Identifiez un seul comportement (fonctionnalité, correction de bug ou résultat de refactoring)
• Écrivez un nouveau test qui exprime le comportement attendu
• Lancez les tests et confirmez que ce nouveau test échoue

L’étape RED n’est terminée que lorsque :

• Vous voyez le test échouer
• Vous confirmez qu’il échoue pour la bonne raison (la bonne assertion, la bonne erreur)

Si l’échec n’est pas le bon (par exemple, le test plante ou échoue pendant le setup), corrigez le test et relancez‑le jusqu’à ce qu’il échoue de manière significative.

2. Ajouter le code minimal pour le faire passer (GREEN)

• Implémentez uniquement le code le plus simple possible pour faire passer le test en échec
• Évitez la conception prématurée, les abstractions inutiles ou la logique superflue
• Exécutez la suite de tests et vérifiez que le nouveau test est maintenant au vert et que les tests existants passent toujours

Les recommandations de la compétence insistent sur le fait que cette étape est volontairement étroite : votre objectif n’est pas de « terminer la fonctionnalité », mais de satisfaire le test.

3. Refactoriser en sécurité (REFACTOR)

Une fois tout au vert :

• Nettoyez le code de production : supprimez les duplications, simplifiez la logique, rendez les noms plus parlants
• Nettoyez les tests : rendez‑les plus lisibles, extrayez des helpers si nécessaire
• Relancez les tests fréquemment pour vérifier que le comportement n’a pas changé

Vous préservez ainsi le comportement tout en améliorant le design, soutenu par votre suite de tests.

4. Répéter la boucle

Pour chaque petit comportement ou cas limite :

• Ajoutez un nouveau test (RED)
• Faites‑le passer (GREEN)
• Refactorisez si besoin (REFACTOR)

La compétence test-driven-development est là pour vous maintenir dans cette boucle et rendre difficile toute rationalisation qui consisterait à sauter des étapes.

Intégration dans votre stack

Les exemples du dépôt sont écrits avec un focus sur JavaScript et TypeScript, mais vous pouvez appliquer les règles TDD quelle que soit votre stack :

• Dans des projets JavaScript/TypeScript (par ex. avec Jest, Vitest ou Mocha) :

  • Créez ou modifiez toujours les tests (par ex. dans *.test.ts ou *.spec.ts) avant d’éditer les fichiers de production
  • Utilisez la boucle Red-Green-Refactor autour de chaque changement de code applicatif

• Dans d’autres langages (par ex. Python, Java, Go, C#) :

  • Faites correspondre les mêmes étapes à votre framework de tests (pytest, JUnit, Go test, xUnit, etc.)
  • La règle stricte « no production code without a failing test » continue de s’appliquer

La compétence en elle‑même ne vous enferme pas dans un framework spécifique ; elle encode des règles de workflow, pas des dépendances de bibliothèque.

Utiliser le guide des testing anti-patterns

Le fichier testing-anti-patterns.md inclus sert de complément à la compétence test-driven-development. Chargez‑le ou référez‑vous‑y chaque fois que vous :

• Écrivez ou modifiez des tests
• Ajoutez des mocks ou des stubs
• Êtes tenté d’ajouter des hooks dédiés aux tests dans des classes ou modules de production

Parmi les principes clés de ce guide :

• Ne testez jamais le comportement d’un mock – les tests doivent vérifier le comportement réel, pas l’existence d’un mock
• N’ajoutez jamais de méthodes réservées aux tests dans les classes de production – gardez les API de production propres
• Ne mockez jamais sans comprendre les dépendances – le sur‑mocking donne une fausse impression de sécurité

Les exemples d’anti‑patterns utilisent des tests au style TypeScript pour illustrer les mauvais et les bons tests, que vous pouvez adapter à votre propre framework de tests.

Adapter le workflow à votre équipe

Après l’installation, vous pouvez adapter les règles de la compétence test-driven-development à votre contexte tout en préservant l’intention principale :

• Vous mettre d’accord sur les types de changements qui doivent suivre un TDD strict (par ex. tous les modules de production, la logique métier, les flux critiques)
• Définir clairement les quelques cas d’exception (par ex. spikes rapides ou code généré), mais les garder explicites
• Intégrer l’Iron Law dans votre checklist de revue de code :
  • « Où est le test en échec qui a piloté ce changement ? »
  • « Le test a‑t‑il été écrit en premier ? »

Cela vous aide à utiliser la compétence comme un standard d’équipe, et pas seulement comme une habitude individuelle.

FAQ

La compétence test-driven-development est‑elle liée à un framework particulier ?

Non. La compétence test-driven-development définit un workflow et des règles, pas un framework de tests en particulier. Les exemples du dépôt s’appuient sur JavaScript et TypeScript, mais vous pouvez appliquer la même boucle Red-Green-Refactor dans n’importe quel langage.

Dois‑je vraiment supprimer le code que j’ai écrit sans tests ?

D’après l’Iron Law dans SKILL.md, oui. Si vous avez écrit du code de production avant un test en échec, la règle est de le supprimer et de repartir des tests. L’idée est d’éliminer toute tentation de considérer les tests comme un simple complément.

Dans quels cas cette compétence n’est‑elle pas adaptée ?

Les recommandations en amont citent quelques exceptions potentielles, comme les prototypes jetables, le code généré ou les fichiers de configuration. Pour des spikes expérimentaux de courte durée, un test-driven-development strict peut être plus lourd que nécessaire. En revanche, pour les fonctionnalités de production, les correctifs de bugs et les refactorings, cette compétence est conçue pour être le choix par défaut.

Comment cette compétence aide‑t‑elle au debug et au refactoring ?

Lors d’une correction de bug ou d’un refactoring :

• Commencez par écrire un test en échec qui reproduit le bug ou décrit le comportement souhaité
• Modifiez ensuite le code jusqu’à ce que le test passe
• Enfin, refactorisez en confiance, car les tests garantissent le comportement

Cela rend le débogage plus systématique et les refactorings plus sûrs.

Puis‑je l’utiliser avec du code legacy existant sans tests ?

Oui, mais vous l’appliquerez probablement de manière progressive :

• Lorsque vous touchez à une zone legacy, commencez par ajouter un test qui capture le comportement actuel ou souhaité
• Regardez‑le échouer (si vous changez le comportement), puis faites‑le passer
• Utilisez la boucle Red-Green-Refactor pour amener progressivement cette partie du code sous tests

Avec le temps, une part croissante de votre code legacy sera protégée par des tests.

Par où commencer après l’installation ?

Après avoir exécuté la commande d’installation, ouvrez :

• SKILL.md pour les règles de base de test-driven-development et la description de Red-Green-Refactor
• testing-anti-patterns.md pour les erreurs courantes à éviter lors de l’écriture de tests

Servez‑vous de ces deux fichiers comme référence pour votre workflow de développement au quotidien.