Test-Driven Development — Iron Law
Discipline TDD stricte : aucun code de production sans test échouant d'abord — boucle rouge-vert-refactor avec loi de fer et démontage des rationalisations
- Quoi
- Discipline TDD stricte : aucun code de production sans test échouant d'abord — boucle rouge-vert-refactor avec loi de fer et démontage des rationalisations
- Coût
- Gratuit
- Prérequis
- un projet où vous pouvez écrire et lancer des tests (npm test / pytest / cargo test / go test ./... ou équivalent).
- Installation
- Copiez le prompt d’installation ci-dessous dans votre Muse — votre agent fait le reste.
Sélectionné par Skill Harbor — un skill de discipline TDD sans compromis, construit sur la loi de fer : aucun code de production sans test échouant d'abord — le code écrit avant le test est supprimé, pas adapté. Il impose le cycle rouge-vert-refactor complet avec vérification obligatoire de l'échec (le test doit échouer pour la bonne raison, pas à cause d'une coquille), du code vert minimal (comportement réel, pas de mocks sauf inévitable), une étape de vérification impeccable, et la règle refactor-seulement-après-vert, plus des standards de bons tests (un comportement, nom clair, code réel) et un tableau des « rationalisations courantes » qui démonte chaque excuse (« trop simple pour être testé », « je testerai après », « le TDD ralentit ») avec la réalité qu'elle mérite. Crédit : @obra. Bémols honnêtes : il est délibérément dogmatique — il rejette explicitement la lecture « l'esprit pas le rituel », et exige même de lancer toute la suite de tests du projet plutôt que le seul fichier touché ; les seules exceptions (prototypes jetables, code généré, config) requièrent de demander à votre partenaire humain. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.
Version :
Installation
Prérequis : un projet où vous pouvez écrire et lancer des tests (npm test / pytest / cargo test / go test ./... ou équivalent). Installe-moi « TDD, loi de fer — Obra ». Une discipline TDD stricte : aucun code de production sans test échouant d'abord, avec le cycle rouge-vert-refactor, des standards de bons tests, et un démontage des rationalisations. Dépôt : https://github.com/obra/superpowers/blob/main/skills/test-driven-development/SKILL.md 1. Récupère le fichier SKILL.md (et les fichiers auxiliaires) depuis le chemin du dépôt dans un dossier temporaire et résume en une ou deux phrases ce qu'il fait. 2. Contrôle de sécurité : examine le SKILL.md et les scripts pour tout comportement suspect (appels réseau inattendus, commandes shell, récolte d'identifiants). Ce dépôt ne doit contenir aucun secret dans le code, les identifiants passent uniquement par le coffre sécurisé. Vérifie que c'est bien le cas ; ARRÊTE sur le moindre drapeau rouge et dis-le-moi. 3. Installe-le comme skill : copie SKILL.md et ses fichiers auxiliaires dans le répertoire des skills de l'agent, dans un dossier nommé « obra-test-driven-development ». 4. Vérifie sans appels réseau : frontmatter valide, fichiers en place. 5. Indique ce qui a été installé, où, et ce qu'il me reste à faire moi-même. GitHub est optionnel : si j'ai un compte GitHub ou la CLI gh, tu peux l'utiliser ; sinon l'accès public suffit. Ne l'exige jamais sauf si c'est dans les prérequis ci-dessus. Règles : ne touche à rien en dehors du dossier temporaire et de la cible d'installation. Si quelque chose semble anormal, arrête et demande-moi.
Questions
Comment installer une création ?
Chaque fiche produit contient un prompt d’installation à copier-coller. Collez-le dans votre Muse et il installe la création pour vous — sans configuration manuelle.
Où va mon argent ?
Directement au vendeur. Skill Harbor ne traite jamais les paiements : le paiement se fait sur la page du vendeur, généralement via Stripe.
Que signifie le ✓ à côté du nom d’un créateur ?
Il signifie que nous avons confirmé l’identité de la personne derrière la fiche. Il ne dit rien sur le code lui-même — vérifiez toujours une création avant de l’installer.