Les agents testeurs : E2E black-box et chasse aux trous

Le test : le terrain idéal de la délégation

Pourquoi les équipes délèguent-elles les tests en premier ? Parce que le test coche toutes les cases du délégable : un objectif vérifiable (le scénario passe ou pas), un cadre étroit (les conventions de la suite existante), un risque borné (un mauvais test se voit en revue, il ne part pas en prod), et un volume que les humains ne comblent jamais (« on ajoutera les tests plus tard » — jamais).

Le dispositif du projet : e2e-blackbox-author

Le flux observé dans l'équipe étudiée :

plan de recette (spec humaine : scénarios S1..S9, critères)
  → agent e2e-blackbox-author : traduit chaque scénario en test Playwright
     • black-box : il teste par l'UI, comme un utilisateur — sans lire l'implémentation
     • conventions de la suite : fixtures, sélecteurs, helpers existants imités
  → MR de tests → revue → la suite tourne 2×/jour contre l'env déployé
  → rapport dans un canal Slack (succès/échecs par famille, version servie)

Le point de design : le black-box est un choix délibéré pour l'agent testeur. En lui interdisant de lire l'implémentation, on l'empêche de « tester ce que fait le code » (tautologique) et on le force à tester ce que promet la spec — exactement la discipline que les humains ont du mal à tenir.

Le compagnon inverse : test-gap-finder (leçon précédente), qui parcourt le code pour lister ce qui n'est PAS couvert — les deux agents travaillent en pince : l'un comble depuis la spec, l'autre audite depuis le code.

La règle de qualité des tests d'agents

Un test généré vaut ce que vaut sa capacité à échouer : la revue d'un test d'agent vérifie d'abord qu'il échouerait si la feature cassait (pas d'assertions creuses, pas de expect(true)), ensuite qu'il est stable (sélecteurs robustes, pas de sleeps magiques). Le projet fait tourner ces suites en continu — un test flaky d'agent se voit en deux jours de rapports Slack.