GUIDE DE TÂCHE · SOURCES ACCESSIBLES
Méthode TDD pour les agents de programmation
Une méthode TDD pratique : convenir d’une interface publique testable, faire échouer un test comportemental, implémenter la plus petite tranche et refactoriser en revue.
Construire ce plan pour mon agent ↗Tester le contrat public, pas les détails internes ; une suite verte ne prouve pas les comportements qu’elle n’exerce pas.
01 · COMBINAISON DE SKILLS
Une combinaison minimale à trois rôles
Chaque rôle a une seule fonction. Le générateur personnalisé peut adapter la sélection à votre agent sans modifier la logique de décision.
tdd
Guide un test de comportement public puis une tranche minimale d’implémentation à la fois ; la refactorisation est une étape de revue distincte.
- Limite principale
- La méthode nécessite un lanceur de tests fonctionnel et un comportement public clairement défini.
- Premier risque
- Confiance injustifiée
- Preuves de source
- Commit figé · c55ee460
create-implementation-plan
Relie le test aux limites réelles du changement.
- Limite principale
- Exiger zéro ambiguïté peut produire des plans démesurés ou une précision trompeuse pour un travail exploratoire.
- Premier risque
- Certitude injustifiée issue de détails générés
- Preuves de source
- Commit figé · 1f564408
Minimal Run and Audit
Exécute la plus petite suite pertinente et consigne le résultat.
- Limite principale
- Il ne choisit pas la cible de reproduction, n’entraîne pas de modèle, ne réalise pas d’analyse générale de l’article et ne masque pas les changements de sens scientifique.
- Premier risque
- Modifications scientifiques masquées en corrections de configuration
- Preuves de source
- Commit figé · fb3ccdf5
02 · MÉTHODE TDD
Une méthode TDD pratique pour les agents de programmation
Ce guide suit le skill TDD figé de Matt Pocock : sa boucle d’implémentation est rouge → vert, tandis que la refactorisation appartient à la revue ultérieure. De nombreux guides généraux résument le TDD par rouge–vert–refactorisation ; cette distinction décrit ce skill particulier, pas une définition universelle du TDD.
- Convenir de l’interface à testerNommez avec le développeur l’interface publique et le comportement avant d’écrire un test. Précisez en une ligne ce que le test détectera et ce qu’il manquera.
- Faire échouer un test comportementalTestez par cette interface publique. Faites échouer le test pour la raison attendue et tirez les résultats attendus de la spécification ou d’un exemple indépendant, pas de l’implémentation.
- Faire réussir une tranche verticaleNe modifiez que le code nécessaire à ce test, puis répétez pour le comportement suivant. Évitez d’écrire toute la suite avant l’implémentation ou de lier les assertions aux détails privés.
- Examiner, refactoriser et vérifierInspectez le diff et réservez le nettoyage à une étape de revue distincte. Après toute refactorisation, relancez les tests affectés ; une suite verte ne couvre que les comportements et environnements effectivement exercés.
Exemple illustratif : un code de réduction expiré
À l’interface publique de paiement, spécifiez la réponse attendue pour un code expiré, puis écrivez un test qui échoue face au comportement actuel. Utilisez l’exigence écrite comme résultat attendu. Il s’agit uniquement d’un exemple, pas d’une mesure comparative ni d’une affirmation sur un projet particulier.
Lire les instructions TDD amont figées ↗ · c55ee46
03 · ACCEPTATION
Comment savoir que la tâche est terminée
- Convenir de l’interface publique à tester et noter ce que le test détecte ou manque.
- Montrer qu’un test comportemental échoue pour la raison attendue avant implémentation.
- Le faire réussir avec le plus petit changement, puis relancer les tests pertinents après revue ou refactorisation.
04 · CONDITIONS D’ARRÊT
Quand s’arrêter
- Le test ne fait que reproduire les détails d’implémentation.
- Un comportement sans rapport est modifié pour faire réussir le test.
- La suite complète est ignorée après modification de code partagé.
05 · MÉTHODE
Comment ce guide a été produit
SkillSignal associe une tâche définie à trois responsabilités distinctes, puis choisit parmi les métadonnées examinées du catalogue. Adéquation à l’agent, état de source, permissions et scores publiés sont évalués par des règles déterministes. Aucun LLM ne rédige ni ne réordonne la recommandation au moment de la requête.