Compétences test-driven-development
📦

test-driven-development

Sûr

Maîtriser le workflow de développement piloté par les tests

Également disponible depuis: ZhanlinCui,DMJGilbert,Cycleaddict,davila7,DYAI2025,CodingCossack,Cygnusfear,obra

Écrire des tests après le code ne prouve pas qu'ils testent réellement quelque chose. Cette compétence impose le cycle Red-Green-Refactor où chaque test doit échouer avant l'implémentation, garantissant que les tests vérifient un comportement réel.

Prend en charge: Claude Codex Code(CC)
📊 70 Adéquat
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 "test-driven-development". Implémenter une fonction qui réessaie les opérations en échec 3 fois

Résultat attendu:

  • Étape 1 (RED) : Écrire le test 'réessaie les opérations en échec 3 fois'
  • Étape 2 : Exécuter le test - vérifier qu'il échoue car la logique de retry n'existe pas
  • Étape 3 (GREEN) : Implémenter une boucle de retry minimale
  • Étape 4 : Exécuter le test - vérifier qu'il passe
  • Étape 5 (REFACTOR) : Extraire la logique de retry si nécessaire

Utilisation de "test-driven-development". Bug : Email vide accepté dans le formulaire

Résultat attendu:

  • RED : test('rejette email vide') - attendu erreur 'Email requis'
  • Vérifier : Le test échoue - le formulaire accepte actuellement l'email vide
  • GREEN : Ajouter une vérification de validation pour l'email vide
  • Vérifier : Le test passe, pas de régressions
  • Résultat : Bug corrigé avec un test empêchant la régression

Audit de sécurité

Sûr
v1 • 2/25/2026

This skill contains only markdown documentation explaining test-driven development methodology. All 57 static analyzer findings for external_commands are false positives - the detected backticks are markdown code fences (```) used for syntax highlighting, not Ruby shell execution. The 6 cryptographic algorithm findings and reconnaissance detections are also false positives from pattern matching on documentation text. No executable code, network calls, or filesystem operations exist in this skill.

2
Fichiers analysés
674
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
23
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Développement de nouvelles fonctionnalités

Utilisez TDD lors de l'implémentation de nouvelles fonctionnalités pour garantir que chaque fonction dispose de tests correspondants qui prouvent le comportement correct avant le commit

Correction de bug avec prévention de régression

Écrivez d'abord un test en échec qui reproduit le bug, puis implémentez la correction, garantissant que le bug ne peut pas régresser

Refactoring en toute confiance

Utilisez la suite de tests existante pour vérifier que le comportement reste inchangé pendant la restructuration ou l'optimisation du code

Essayez ces prompts

Cycle TDD de base 
Je dois implémenter [feature]. Aidez-moi à écrire d'abord un test en échec qui décrit le comportement attendu, puis guidez-moi à travers Red-Green-Refactor.
Correction de bug avec TDD 
Bug : [describe bug]. Aidez-moi à écrire un test qui reproduit ce bug (doit échouer), puis implémentez la correction minimale pour le faire passer.
Revue de qualité des tests 
Examinez mon test pour [function]. Teste-t-il un comportement réel ou un comportement mocké ? Le nom du test est-il clair ? Teste-t-il une seule chose ?
Vérification des anti-patterns TDD 
Je suis sur le point de [action]. Vérifiez si cela viole les principes TDD. Est-ce que je teste un comportement mocké ? Est-ce que j'ajoute du code uniquement pour les tests ? Est-ce que je moque sans comprendre ?

Bonnes pratiques

  • Regardez toujours le test échouer avant d'implémenter - cela prouve que le test teste réellement quelque chose
  • Écrivez le code minimal pour passer le test - pas de fonctionnalités supplémentaires, pas de sur-ingénierie
  • Supprimez le code d'implémentation si vous sautez le cycle TDD et recommencez avec les tests en premier

Éviter

  • Écrire du code d'implémentation avant que le test n'existe
  • Tester le comportement mocké au lieu du comportement réel du code
  • Ajouter des méthodes réservées aux tests dans les classes de production

Foire aux questions

Que faire si j'ai déjà écrit du code d'implémentation ?
Supprimez-le. Le temps est déjà dépensé. Réécrivez en utilisant TDD en commençant par un test en échec. Garder du code non vérifié est une dette technique.
Puis-je écrire des tests après l'implémentation ?
Non. Les tests écrits après réussissent immédiatement, ne prouvant rien. Vous testez ce que vous avez construit, pas ce qui est requis. TDD nécessite de commencer par le test.
Que faire si le code est trop simple pour être testé ?
Le code simple casse aussi. Un test de 30 secondes prévient les futurs bugs. Si cela vaut la peine d'être livré, cela vaut la peine d'être testé.
Comment gérer le code existant sans tests ?
Ajoutez des tests pour le comportement existant avant de faire des changements. Testez le comportement actuel d'abord, puis utilisez TDD pour les nouvelles fonctionnalités.
Que faire si la configuration de mon test est trop complexe ?
Des tests complexes indiquent un design complexe. Simplifiez l'interface, extrayez des helpers, ou utilisez l'injection de dépendances.
Quand puis-je sauter TDD ?
Uniquement pour les prototypes jetables, le code généré, ou les fichiers de configuration. Pour le code de production, utilisez toujours TDD sauf si votre partenaire humain approuve une exception.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/test-driven-development

Réf

main

Structure de fichiers

📄 SKILL.md

📄 testing-anti-patterns.md