Compétences tdd
📦

tdd

Sûr

Écrire des tests en utilisant le développement piloté par les tests

Également disponible depuis: Benny9193

Écrire des tests après le code crée des systèmes fragiles qui cassent lors des refactorisations. Cette compétence vous guide à travers le développement piloté par les tests où les tests définissent le comportement avant l'implémentation, produisant un code plus propre et une refactorisation fiable.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "tdd". Aidez-moi à construire une fonctionnalité pour ajouter des articles à un panier

Résultat attendu:

Je vais vous guider à travers TDD pour cette fonctionnalité. Première question : que doit-il se passer quand un utilisateur ajoute un article ? Devrions-nous supporter la quantité ? Quel comportement doit être vérifiable ?

Utilisation de "tdd". Écrire des tests pour l'authentification utilisateur

Résultat attendu:

Pour les tests d'authentification, concentrez-vous sur les interfaces publiques : connexion, déconnexion, gestion de session. Je recommande des tests de type intégration plutôt que de mocker la logique d'authentification interne. Quels services externes votre auth utilise-t-il ?

Utilisation de "tdd". Mes tests cassent chaque fois que je refactorise

Résultat attendu:

Vos tests sont probablement couplés aux détails d'implémentation. Les bons tests vérifient le comportement à travers les interfaces publiques. Identifions quels tests cassent et ce qu'ils testent.

Audit de sécurité

Sûr
v1 • 4/19/2026

All 48 static findings are false positives. The skill contains educational TDD documentation with code examples. External command flags were triggered by ASCII workflow diagrams (RED→GREEN patterns). Cryptographic algorithm flags were triggered by testing patterns like jest.mock() and StripeClient(). No malicious code or prompt injection detected.

6
Fichiers analysés
307
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Construire de nouvelles fonctionnalités avec TDD

Lors du démarrage d'une nouvelle fonctionnalité, cette compétence aide à écrire les tests en premier qui définissent le comportement attendu, puis guide vers une implémentation minimale pour faire passer ces tests.

Corriger des bugs avec des tests qui échouent

Lorsqu'un bug est signalé, cette compétence aide à écrire un test qui échoue et qui reproduit le bug, puis guide vers la correction du code pour faire passer le test.

Améliorer le code legacy par refactorisation

Avant de refactoriser du code legacy, cette compétence aide à écrire des tests d'intégration qui capturent le comportement actuel, assurant que les refactorisations ne cassent pas les fonctionnalités existantes.

Essayez ces prompts

Nouvelle fonctionnalité avec TDD 
J'ai besoin d'ajouter [feature] à [module]. Aidez-moi à utiliser TDD pour construire cela. Commencez par demander quels comportements tester en premier.
Correction de bug avec TDD 
Il y a un bug où [description]. Aidez-moi à écrire un test qui échoue et qui reproduit cela, puis corrigez-le.
Améliorer la couverture de tests 
Je veux de meilleurs tests pour [module]. Analysez mes tests actuels et suggérez des améliorations en suivant les principes TDD.
Refactoriser avec confiance 
Je veux refactoriser [module]. Aidez-moi à écrire des tests qui capturent le comportement actuel en premier, puis guidez ma refactorisation.

Bonnes pratiques

  • Écrire un test à la fois et juste assez de code pour le faire passer
  • Utiliser uniquement les interfaces publiques ; les tests doivent survivre aux refactorisations internes
  • Préférer les tests de type intégration qui vérifient le comportement observable plutôt que de mocker les parties internes

Éviter

  • Écrire tous les tests en premier puis toute l'implémentation (découpage horizontal)
  • Mocker les collaborateurs internes plutôt que de tester à travers les interfaces publiques
  • Écrire des tests qui vérifient les détails d'implémentation plutôt que le comportement

Foire aux questions

Quand dois-je écrire les tests dans TDD ?
Écrivez le test avant tout code d'implémentation. Le test définit quel comportement vous voulez avant de le construire.
Combien de tests dois-je écrire à la fois ?
Écrivez un test à la fois. Cela garde vos cycles petits et concentrés sur un comportement à la fois.
Que dois-je tester si je ne peux pas tout tester ?
Concentrez-vous sur les chemins critiques et la logique complexe. Confirmez avec votre utilisateur quels comportements comptent le plus pour votre application.
Dois-je mocker mes propres classes ou modules ?
Non. Mockez uniquement aux limites du système comme les API externes, les bases de données et les systèmes de fichiers. Votre propre code doit être testé à travers de vraies interfaces.
Quand dois-je refactoriser dans TDD ?
Refactorisez seulement quand tous les tests passent (état vert). Ne refactorisez jamais tant que les tests échouent.
Comment savoir si mon test est bon ?
Un bon test casse quand le comportement casse mais survit aux refactorisations internes. Si renommer une fonction interne casse votre test, le test testait l'implémentation et non le comportement.

Détails du développeur

Auteur

mattpocock

Licence

MIT

Dépôt

https://github.com/mattpocock/skills/tree/main/tdd/

Réf

main

Structure de fichiers

📄 deep-modules.md

📄 interface-design.md

📄 mocking.md

📄 refactoring.md

📄 SKILL.md

📄 tests.md