Compétences test-driven-development
📦

test-driven-development

Sûr

Appliquer le développement piloté par les tests

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

Écrire des tests après le code conduit à une confiance erronée et à des cas limites manqués. Cette compétence impose la discipline TDD : écrire d'abord un test qui échoue, puis implémenter juste assez de code pour le faire passer.

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 "test-driven-development". Je dois ajouter une fonction qui valide les adresses e-mail

Résultat attendu:

Commençons avec le TDD. D'abord, j'écris un test qui échoue :

```typescript
test('rejects invalid email', () => {
expect(validateEmail('invalid')).toBe(false);
});
```

Maintenant, je vais exécuter ce test pour confirmer qu'il échoue...

Utilisation de "test-driven-development". La fonction login devrait gérer les mauvais mots de passe

Résultat attendu:

En suivant le TDD, d'abord le test :

```typescript
test('rejects wrong password', async () => {
const result = await login('user@test.com', 'wrongpass');
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
});
```

Exécution du test pour vérifier qu'il échoue...

Audit de sécurité

Sûr
v1 • 2/24/2026

This is a legitimate Test-Driven Development educational skill. The static analyzer detected 73 potential issues, but after semantic evaluation, all findings are FALSE POSITIVES. The 'external_commands' detections are markdown code block delimiters (backticks) in documentation, not actual shell execution. The 'weak cryptographic algorithm' and 'network reconnaissance' detections are similarly false positives triggered by keywords in educational context. No executable malicious code exists in this skill.

2
Fichiers analysés
672
Lignes analysées
1
résultats
1
Total des audits
Problèmes à risque moyen (1)
Markdown Code Block Delimiters Flagged as Shell Execution
The static scanner detected 'Ruby/shell backtick execution' patterns in markdown files. These are FALSE POSITIVES - the backticks are markdown code fence delimiters (```typescript, ```bash) used for syntax highlighting in documentation, not runtime command execution. The skill is educational content about TDD methodology with no actual shell commands being executed.
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

Implémentation d'une nouvelle fonctionnalité

Lors de la création d'une nouvelle fonctionnalité, écrivez d'abord le test qui définit le comportement attendu, regardez-le échouer, puis implémentez pour le faire passer

Workflow de correction de bug

Lors de la correction d'un bug, écrivez d'abord un test qui reproduit le bug, regardez-le échouer, puis corrigez le code pour le faire passer

Refactoring en toute confiance

Avant de refactoriser, assurez-vous que des tests existent. Les tests vérifient que le comportement reste correct après les modifications du code

Essayez ces prompts

Démarrer le TDD pour une nouvelle fonctionnalité 
Je dois implémenter [décrire la fonctionnalité]. En suivant le TDD, écrivez d'abord un test qui échoue et qui définit le comportement attendu. N'écrivez pas encore de code d'implémentation.
Vérifier la phase Rouge 
Exécutez le test que je viens d'écrire et confirmez qu'il échoue pour la bonne raison (fonctionnalité manquante, pas à cause de fautes de frappe). Montrez-moi le message d'échec exact.
Phase Verte - Implémentation minimale 
Maintenant, écrivez le code minimal nécessaire pour faire passer le test. N'ajoutez pas de fonctionnalités supplémentaires et ne refactorisez pas. Faites simplement passer le test.
TDD pour correction de bug 
Il y a un bug où [décrire le bug]. Écrivez d'abord un test qui reproduit ce bug et qui échoue. Ensuite, je le corrigerai.

Bonnes pratiques

  • Écrire un test à la fois - se concentrer sur un comportement unique
  • Nommer les tests par le comportement qu'ils vérifient, pas par ce qui est testé
  • Toujours regarder le test échouer avant d'écrire l'implémentation
  • Garder l'implémentation minimale - passer uniquement le test actuel

Éviter

  • Écrire du code d'implémentation avant les tests (puis 'adapter' les tests)
  • Garder le code d'implémentation qui échoue comme 'référence' pendant l'écriture des tests
  • Les tests qui passent immédiatement - ils ne prouvent rien
  • Tester le comportement des mocks au lieu du comportement réel des composants

Foire aux questions

Qu'est-ce que le développement piloté par les tests ?
Le TDD est une méthodologie où vous écrivez d'abord un test qui échoue, puis écrivez le code minimal pour le faire passer, puis refactorisez. Le cycle est : Rouge (échec), Vert (succès), Refactoriser.
Pourquoi écrire les tests avant le code ?
Les tests écrits après le code passent immédiatement, ce qui ne prouve rien. Écrire les tests d'abord vous force à définir le comportement souhaité et prouve que le test détecte réellement les bugs.
Que faire si le test est difficile à écrire ?
La difficulté à écrire des tests indique souvent que la conception est trop complexe. Simplifiez l'interface ou utilisez l'injection de dépendances pour rendre le code testable.
Puis-je sauter le TDD pour du code simple ?
Non. Le code simple peut aussi casser. Le temps pour écrire un test est minimal, et cela prouve que le code fonctionne et prévient les régressions futures.
Que faire si j'ai déjà écrit l'implémentation ?
Supprimez-le. Recommencez avec le TDD. Garder le code existant et ajouter des tests après va à l'encontre de l'objectif et donne une fausse confiance.
Le TDD ralentit-il le développement ?
Non. Le TDD trouve les bugs avant le commit, prévient les régressions et permet le refactoring en toute sécurité. Le débogage a posteriori est plus lent que le TDD.

Détails du développeur

Auteur

ZhanlinCui

Licence

MIT

Dépôt

https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/test-driven-development

Réf

main

Structure de fichiers

📄 SKILL.md

📄 testing-anti-patterns.md