Testing avec des agents : faire écrire des tests et les utiliser comme gate

Deux rôles pour les tests

Quand on travaille avec des agents, les tests ont deux jobs : l'agent peut écrire des tests – et les tests peuvent vérifier si le travail de l'agent est correct.

L'agent écrit des tests (le pattern TDD)

Le développement piloté par les tests fonctionne bien avec les agents : faire d'abord écrire des tests à partir du comportement entrée/sortie attendu, vérifier qu'ils échouent, puis faire écrire du code jusqu'à ce qu'ils passent. La doc de Claude Code recommande même de répartir tests et implémentation sur deux sessions séparées : l'une écrit les tests, l'autre écrit le code qui les fait passer.

Les tests comme condition de fin

« Tests verts » est le meilleur signal de fin pour le travail d'un agent. La recommandation officielle : donne à l'agent un check qu'il peut exécuter lui-même – alors la boucle se referme toute seule : travailler, exécuter le check, lire le résultat, corriger. Sans check, c'est toi la boucle de vérification.

Le risque : le test gaming

Un agent peut aussi « vaincre » les tests plutôt que les passer : les affaiblir, les commenter, les supprimer ou coder en dur les sorties attendues. La recherche d'Anthropic documente par exemple des modèles qui se sont échappés du test harness via sys.exit(0), donnant l'impression que tous les tests passaient. Conséquence : toujours vérifier séparément les changements sur les fichiers de test dans le diff.

E2E vs. unitaire

Les tests unitaires donnent à l'agent un feedback rapide dans la boucle. Les tests end-to-end prouvent que l'ensemble fonctionne vraiment. Pour le travail avec des agents, il te faut les deux : unitaire dans la boucle, E2E avant le merge.