المهارات tdd-workflow
📦

tdd-workflow

آمن ⚙️ الأوامر الخارجية

Implémenter le flux de travail TDD (Test-Driven Development)

متاح أيضًا من: DoubleslashSE

Les développeurs perdent du temps à déboguer du code sans tests. Cette compétence impose le cycle RED-GREEN-REFACTOR pour construire un logiciel fiable en toute confiance.

يدعم: Claude Codex Code(CC)
🥉 74 برونزي
1

تنزيل ZIP المهارة

2

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

3

فعّل وابدأ الاستخدام

اختبرها

استخدام "tdd-workflow". Implémenter une fonction pour valider les adresses e-mail

النتيجة المتوقعة:

  • Phase RED : Créé le test 'should accept valid email format' - le test échoue (pas d'implémentation encore)
  • Phase GREEN : Implémenté la validation regex minimale - le test passe
  • Phase REFACTOR : Logique de validation extraite dans une fonction séparée, messages d'erreur améliorés

استخدام "tdd-workflow". Corriger l'exception de pointeur nul dans la recherche d'utilisateur

النتيجة المتوقعة:

  • Phase RED : Le test reproduit l'exception de pointeur nul - échec confirmé
  • Phase GREEN : Ajouté la vérification de null avant d'accéder aux propriétés utilisateur - le test passe
  • Phase REFACTOR : Créé un helper de recherche null-safe réutilisable utilisé dans tout le code

التدقيق الأمني

آمن
v1 • 2/25/2026

All static analysis findings are false positives. The arrow character (→) was misidentified as shell backtick execution. References to 'crypto' and 'reconnaissance' are pattern matching errors on plain text documentation. This is a safe TDD methodology guide. External commands are legitimately used for running test suites.

1
الملفات التي تم فحصها
155
الأسطر التي تم تحليلها
1
النتائج
1
إجمالي عمليات التدقيق

عوامل الخطر

⚙️ الأوامر الخارجية (1)
تم تدقيقه بواسطة: claude

درجة الجودة

38
الهندسة المعمارية
100
قابلية الصيانة
87
المحتوى
50
المجتمع
100
الأمان
91
الامتثال للمواصفات

ماذا يمكنك بناءه

Développement de nouvelle fonctionnalité

Construire des fonctionnalités fiables en écrivant les tests d'abord, puis en implémentant le code minimal pour passer chaque test.

Correction de bug avec protection de régression

Écrire un test qui reproduit le bug, le corriger, puis refactoriser avec la confiance que le bug reste corrigé.

Amélioration de la qualité du code d'équipe

Utiliser le modèle TDD multi-agent où différents agents écrivent des tests, implémentent du code et refactorisent.

جرّب هذه الموجهات

Démarrer TDD pour une nouvelle fonction
Je veux implémenter une fonction qui [décrire le comportement]. Écrire d'abord un test en échec suivant la phase RED du TDD. Le test devrait décrire le comportement attendu clairement.
Compléter le cycle RED-GREEN-REFACTOR
Implémentons [feature] en utilisant TDD. Étape 1 : Écrire un test en échec. Étape 2 : Écrire le code minimal pour passer. Étape 3 : Refactoriser pour la clarté. Guidez-moi à travers chaque phase.
Appliquer le modèle AAA au test
Revoir ce test et le restructurer en utilisant le modèle AAA (Arrange, Act, Assert). Identifier quelles données nécessitent une configuration, quel code s'exécute, et quel résultat vérifier.
Session TDD multi-agent
Exécuter une session TDD multi-agent pour [feature]. L'Agent A écrit le test en échec, l'Agent B implémente pour passer, l'Agent C refactorise. Coordonner les transferts entre phases.

أفضل الممارسات

  • Toujours regarder le test échouer avant d'écrire le code d'implémentation - cela valide que le test fonctionne
  • Écrire une assertion par test pour isoler les échecs et clarifier l'intention
  • Valider après chaque cycle RED-GREEN-REFACTOR complet pour maintenir des changements petits et vérifiables

تجنب

  • Écrire du code avant que le test n'échoue - cela contredit l'objectif du TDD et indique souvent que vous ne comprenez pas les exigences
  • Tester des détails d'implémentation comme les noms de méthodes privées - les tests devraient vérifier le comportement, pas la structure interne
  • Multiples assertions par test - rend les échecs ambigus et viole le principe de responsabilité unique

الأسئلة المتكررة

Que faire si mon test n'échoue pas du premier coup ?
Cela signifie soit que le test ne vérifie pas correctement le comportement, soit que le code existe déjà. Examiner la logique du test ou vérifier si la fonctionnalité a déjà été implémentée.
Puis-je sauter le TDD pour des changements simples ?
Simple est subjectif. Si vous êtes assez confiant pour sauter le test, le changement devrait être trivial à tester de toute façon. Le TDD attrape les cas limites que vous pourriez manquer.
Comment gérer les appels de base de données ou d'API dans le TDD ?
Utiliser des mocks ou des fakes pour isoler l'unité testée. Tester la logique, pas la dépendance externe. Les tests d'intégration peuvent vérifier les connexions réelles séparément.
Que faire si le TDD ralentit mon développement ?
Le TDD semble plus lent initialement mais réduit le temps de débogage et de régression. L'investissement porte ses fruits en qualité de code et en confiance pendant le refactoring.
Devrais-je utiliser le TDD pour les composants UI ?
Le TDD a moins de valeur pour la mise en page UI pure. L'utiliser pour la logique de composant et la gestion d'état. Les outils de régression visuelle complètent le TDD pour les tests UI.
Comment prioriser quels tests écrire en premier ?
Commencer par le happy path (comportement attendu), puis les cas d'erreur, puis les cas limites. Les tests de performance viennent en dernier après que la fonctionnalité soit complète.

تفاصيل المطور

المؤلف

sickn33

الترخيص

MIT

مرجع

main

بنية الملفات

📄 SKILL.md