Les tests sont là où Claude Code gagne sa croûte. Le debug est là où il devient bizarrement impressionnant.

Mais c’est aussi là qu’un workflow bâclé dérape vite. Laissez un agent « réparer » un test de la mauvaise manière et vous livrez une CI verte avec une feature cassée. Laissez-le « débuger » un test flaky et il pourrait simplement le supprimer.

Voici les patterns qui marchent — et la règle qui les garde honnêtes.

La règle unique

Opérationnalisez ça avec deux sub-agents qui ne peuvent pas être le même agent :

• test-writer — n’ajoute ou ne modifie que des tests.
• test-fixer — ne modifie que le code de prod pour faire passer les tests.

Si test-fixer veut un jour toucher un test, il doit escalader vers un humain. C’est le contrat.

Pattern 1 — Délégation test-first

Pour les nouvelles features, voici le workflow le plus propre :

> /agents test-writer
> Objectif : Écris des cas vitest pour lib/cache.ts couvrant :
>   - Éviction LRU à maxSize=3
>   - Expiration TTL avec fake timers
>   - get(missing) retourne undefined
> Contraintes : vitest, fake timers via vi.useFakeTimers().
> DoD : Tests écrits, tous actuellement ROUGES.

La sortie ce sont des tests qui échouent. C’est correct.

> /agents test-fixer
> Fais passer les nouveaux tests sans modifier tests/cache.test.ts.

test-fixer implémente le LRU + TTL dans lib/cache.ts. Tests verts. Diff petit, focalisé, relisable.

C’est bien plus propre que « écris le cache et les tests en une fois » parce que l’auteur des tests est aveugle à l’implémentation. Ça attrape les erreurs d’API tôt.

Pattern 2 — Le chuchoteur de stack-traces

Quand quelque chose explose dans les logs de prod, collez la stack trace. Claude Code est déraisonnablement bon là-dessus.

> Lis cette stack trace et dis-moi laquelle des trois causes les plus probables est la bonne,
  avec preuves fichier:ligne :

[colle la stack]

Puis propose un fix de 5 lignes qui adresse SEULEMENT cette cause.

Deux notes :

• « Trois causes les plus probables » l’oblige à énumérer, pas à se sur-engager.
• « Fix de 5 lignes » plafonne le blast radius.

Je trouve que ~70 % des sessions de debug « il se passe quoi ici ? » se terminent après ce seul round.

Pattern 3 — Tri des tests flakies

Les tests flakies sont le fléau de la CI. L’agent est excellent pour les classer :

> Lance la suite de tests 10 fois. Liste tout test qui :
>   - A échoué au moins une fois et passé au moins une fois.
>   - Sors l'erreur exacte du run qui a échoué.
> NE modifie PAS de code.

Vous récupérez un tableau de triage. À partir de là, vous demandez :

> Pour le test X (flaky), classe la cause probable :
>   - Race condition
>   - Dépendant du temps (horloge réelle vs fake)
>   - Réseau / dépendance externe
>   - Fuite de ressource d'un test précédent
> Cite les preuves fichier:ligne.

La classification de l’agent est rarement 100 % juste mais elle est presque toujours « dans le bon quartier ». C’est suffisant pour pointer l’enquête dans la bonne direction.

Pattern 4 — Bisecter une régression

Vous avez git bisect et l’agent a git log. Combinez-les :

> L'endpoint /api/x retournait 200 la semaine dernière et retourne 500 maintenant.
> Trouve le commit fautif en :
>   1. git log --oneline depuis le dernier déploiement bon.
>   2. Pour chaque commit touchant /api/x ou ses imports, résume le changement en une ligne.
>   3. Identifie le coupable le plus probable et explique pourquoi.
>   4. NE lance AUCUN code.

C’est plus rapide qu’un git bisect binaire parce que l’agent lit les diffs au fil de l’eau. Idéal pour des bases de code assez petites pour que l’ensemble candidat fasse < 50 commits.

Pattern 5 — La couverture comme boucle de coaching

Sous-coté :

> Lance pnpm test --coverage sur lib/auth/.
> Rapporte les lignes non couvertes.
> Pour chaque branche non couverte, propose une description en une ligne d'un test
> qui la couvrirait. NE écris PAS les tests.

Vous récupérez une punch list. Ensuite test-writer les abat un par un.

Pourquoi c’est mieux que « atteins 90 % de couverture automatiquement » : vous voyez la punch list et pouvez déprioriser les branches idiotes (chemins d’erreur impossibles, defaults d’exhaustive-switch).

Choses à ne jamais déléguer dans les tests

• Décider quoi tester. C’est de la connaissance produit.
• Décider quand le « assez bien » est assez bien. Le seuil de couverture est un choix de valeurs.
• Marquer un test comme « skip » ou « todo ». Toujours humain. Toujours.

L’agent suggère ; l’humain décide ce qui compte comme prêt.

Anti-patterns de debug que je vois chaque semaine

• « Fais juste passer le test. » Catastrophique. À chaque fois. Le reviewer le verra ; on ne devrait pas demander ça à l’agent.
• « Ajoute // @ts-ignore pour calmer le build. » Le sub-agent doit refuser. Configurez-le ainsi dans .claude/agents/test-fixer.md :

# règles
- Ne jamais ajouter @ts-ignore, @ts-expect-error ou eslint-disable.
- Si tu ne peux pas corriger une erreur de type, escalade.

• « Mets à jour le snapshot. » Parfois légitime, mais l’agent doit toujours montrer le diff et expliquer pourquoi le snapshot a changé avant de le mettre à jour.

Le résultat après un trimestre

Sur la base de code où je fais tourner ça depuis ~3 mois :

• Temps moyen pour trier un CI flaky : ~12 min → ~3 min.
• Temps moyen pour déboguer une stack trace de prod : ~20 min → ~5 min.
• Delta de couverture de test sur les nouvelles features : bruyant, mais en moyenne +8 points de pourcentage.

Aucun de ces chiffres n’est de la magie d’agent. Ils sont le résultat de standardiser le workflow de tests avec des contraintes qu’on ne pourrait pas facilement standardiser autour d’humains.

---

Article suivant : Workflows d’équipe — comment les équipes d’ingénierie intègrent Claude Code aujourd’hui, du anti-pattern « une seule licence » au pattern partagé .claude/ dans git qui scale.