Sous-agent rédacteur de tests (.claude/agents)

---
name: redacteur-tests
description: Rédige et exécute des tests automatisés pour du code nouveau ou modifié. À utiliser quand une fonctionnalité est terminée mais pas encore couverte par des tests.
tools: Read, Grep, Glob, Edit, Write, Bash
model: inherit
---
 
Tu écris des tests automatisés. Tu ne modifies PAS le code de production :
si un test révèle un bug, tu le signales au lieu de le corriger.
 
## Démarche
 
1. Identifie le framework de test et les conventions du projet : lis
   quelques tests existants, la configuration et les scripts de test
   (`package.json`, `pyproject.toml`…).
2. Liste les comportements à couvrir : cas nominal, cas limites
   (entrée vide, valeur nulle, bornes), cas d'erreur.
3. Écris les tests à côté des tests existants, en reprenant leur style,
   leurs fixtures et leurs helpers.
4. Exécute uniquement les tests que tu as ajoutés, puis corrige les tests
   (pas le code) jusqu'à ce qu'ils passent ou qu'un vrai bug soit démontré.
 
## Règles
 
- Un test = un comportement, avec un nom qui le décrit.
- Aucun appel réseau réel, aucune dépendance à l'heure ou à l'ordre d'exécution.
- Ne jamais utiliser `skip` ou affaiblir une assertion pour obtenir un succès.
 
## Compte rendu
 
Termine par : les fichiers de test créés ou modifiés, la commande pour les
lancer, le résultat de l'exécution, et les bugs éventuellement découverts
(avec le test qui les reproduit).

Écrire des tests après coup est une tâche bien délimitée, idéale pour un sous-agent : on lui confie une fonctionnalité, il étudie les conventions du projet, rédige les tests, les exécute et rend un compte rendu. Pendant ce temps, la conversation principale n'est pas encombrée par la lecture des fichiers de configuration ou par les sorties des exécutions successives.

Anatomie du fichier

• name : redacteur-tests, l'identifiant utilisé pour l'invoquer ;
• description : précise le moment opportun, « quand une fonctionnalité est terminée mais pas encore couverte » ;
• tools : Read, Grep, Glob pour explorer, Edit et Write pour créer les fichiers de test, Bash pour les exécuter ;
• model : inherit, soit le modèle de la session en cours.

Le corps du fichier fixe une règle essentielle : le sous-agent ne modifie pas le code de production. S'il découvre un bug, il le signale avec le test qui le reproduit, et c'est à vous (ou à la session principale) de décider de la correction.

Installation et utilisation

1. Placez le fichier dans .claude/agents/ (partagé via Git) ou ~/.claude/agents/ (personnel).
2. Demandez par exemple : « Utilise le sous-agent redacteur-tests pour couvrir le module de facturation ».
3. Relisez les tests produits comme n'importe quel code : un test qui passe n'est utile que s'il vérifie le bon comportement.

Comment l'adapter

• Commande de test : si votre projet exige une commande particulière, écrivez-la dans le corps du fichier plutôt que de laisser le sous-agent la déduire.
• Limiter l'écriture : l'outil Edit peut modifier n'importe quel fichier. Pour cantonner le sous-agent aux dossiers de test, ajoutez dans settings.json des règles de permission Edit(...) adaptées, ou un hook PreToolUse qui vérifie le chemin.
• Couplage avec une règle : la ressource « règle tests » de cette page (fichier .claude/rules/tests.md) donne des conventions d'écriture que le sous-agent chargera en lisant vos tests existants.

Pièges fréquents

• Tests qui valident le bug : écrits à partir du code existant, des tests peuvent figer un comportement erroné. Décrivez le comportement attendu dans votre demande.
• Assertions affaiblies : la consigne interdit explicitement skip et les assertions vidées de leur sens ; vérifiez-le en relecture.
• Exécution de toute la suite : sur un gros projet, demander l'exécution des seuls tests ajoutés fait gagner beaucoup de temps.

La leçon Les sous-agents explique comment choisir les outils d'un sous-agent et quand préférer la délégation.