Comment tester du code généré par l'IA : des tests de bout en bout indépendants

Ce que veut dire tester du code généré par l'IA

Tester du code généré par l'IA, c'est prouver que votre application fait toujours ce dont ses utilisateurs ont besoin après qu'un agent de codage IA l'a modifiée.Qui a écrit les lignes n'importe pas à l'utilisateur.Ce qui compte, c'est que la connexion fonctionne toujours, que le total soit toujours juste et que le bouton soit toujours là.

Les agents de codage font désormais bien plus que compléter une ligne.Claude Code, Cursor, GitHub Copilot, OpenAI Codex et Devin peuvent prendre une tâche, modifier de nombreux fichiers, exécuter des commandes et ouvrir une pull request.Certaines équipes vont plus loin et pratiquent le vibe coding : elles décrivent ce qu'elles veulent, acceptent ce qui revient, et ne lisent presque jamais le code.

Le code arrive désormais plus vite que quiconque ne peut le relire.Un relecteur reçoit un diff de centaines de lignes réparties sur une douzaine de fichiers, et un diff ne montre jamais l'application en marche.Tester dans le développement agentique, c'est combler cet écart : une vérification de l'application terminée qui ne dépend pas de la lecture du code.

Pourquoi les tests de l'agent lui-même ne suffisent pas

La première idée est de demander aussi à l'agent d'écrire des tests.Faites-le : les tests unitaires attrapent de vraies erreurs, et un agent les écrit vite.Mais un test écrit par l'agent qui a écrit le code partage sa compréhension de la tâche.Si l'agent a mal compris l'exigence, le code et le test sont d'accord entre eux, et les deux sont faux.

Les tests au niveau du code ont bien d'autres angles morts qu'une exigence mal comprise.

Ces angles morts ont un point commun : ils sont invisibles depuis l'intérieur du code.La preuve doit venir de l'extérieur, de l'application en marche, vue comme un utilisateur la voit.

Les tests de bout en bout auto-réparateurs règlent-ils le problème ?

Les tests de bout en bout sont la réponse classique.Un test de bout en bout pilote la vraie application par son interface, comme le fait un utilisateur, et vérifie ce qui se passe.La plupart des équipes les écrivent sous forme de code, avec Playwright, Cypress ou Selenium : vous écrivez un sélecteur pour chaque élément et une ligne de code pour chaque clic.

Les agents écrivent bien ce code, et les outils les aident désormais.Playwright fournit des agents de test : un planificateur, un générateur, et un réparateur qui rejoue un test en échec, inspecte la page et corrige le test jusqu'à ce qu'il réussisse, ou le marque comme ignoré quand il estime que la fonctionnalité est cassée.Chez Cypress, cy.prompt transforme des étapes écrites en anglais courant en commandes Cypress et répare une étape quand son sélecteur ou son texte change d'une exécution à l'autre.Playwright MCP permet à un agent de piloter un navigateur à travers les instantanés d'accessibilité de la page.

L'auto-réparation est utile, car la plupart des tests de bout en bout cassés viennent d'un sélecteur renommé, pas d'un bug.Le risque apparaît quand un seul agent fait tout : il écrit la fonctionnalité, écrit le test, et répare le test quand il échoue.Chaque réparation est raisonnable en elle-même.Ensemble, elles peuvent faire glisser le test de ce dont l'utilisateur a besoin vers ce que le code se trouve faire.

Pour comparer les outils de tests de bout en bout eux-mêmes, voir l'étude comparative.

Comment tester de bout en bout du code généré par l'IA ?

Six habitudes font des tests de bout en bout un garde-fou qu'un agent ne peut pas contourner à force d'arguments.Aucune n'exige un outil particulier.

1. 1

   Écrire les parcours qui ne doivent jamais casser

   Listez les cinq à dix parcours dont vos utilisateurs ne peuvent pas se passer : s'inscrire, se connecter, rechercher, ajouter au panier, payer, exporter un rapport.Écrivez chacun comme vous l'expliqueriez à un nouveau testeur, avec son résultat attendu.Cette liste est votre spécification, et elle vous appartient, pas à l'agent.

2. 2

   Créer le test avant que l'agent écrive le code

   Quand un parcours est nouveau, créez d'abord son test de bout en bout, à partir de la maquette ou des étapes.L'agent travaille alors vers une cible qu'il n'a pas choisie.Le test échoue tant que la fonctionnalité ne marche pas : le développement piloté par les tests, appliqué aux agents.

3. 3

   Vérifier ce que voit l'utilisateur

   Vérifiez l'écran : les mots qu'un utilisateur lit, l'aspect d'un élément, la façon dont les choses sont agencées.Évitez les vérifications d'identifiants internes, de noms de classes et d'états que seul le code connaît, car c'est précisément ce qu'un agent change librement.Un test ancré sur l'écran survit à une réécriture du code en dessous.

4. 4

   Garder les tests hors de portée de l'agent

   Rangez les tests à côté du code, mais faites en sorte que chaque modification qui les touche exige la relecture d'une personne.Sur GitHub, une entrée CODEOWNERS pour le dossier des tests, avec l'approbation des propriétaires du code exigée avant une fusion, fait exactement cela.L'agent peut exécuter les tests et proposer une modification de l'un d'eux.Il ne fusionne jamais cette modification seul.

5. 5

   Les exécuter sur chaque pull request

   Exécutez les tests de régression de bout en bout sur chaque pull request que l'agent ouvre, sur une machine qui affiche la vraie application, et faites en sorte qu'un échec bloque la fusion.Un résultat qui ne fait qu'avertir est vite ignoré.Ce qui fait réussir les exécutions à chaque fois, d'une taille d'écran fixe à un état de départ connu, est expliqué dans Exécuter un test.

6. 6

   Rendre les échecs lisibles par l'agent et par vous

   Un test échoué doit dire ce qui a échoué, où, et en quoi l'écran diffère de ce qui était attendu, avec des images.L'agent s'en sert pour proposer un correctif.Vous vous en servez pour décider si le changement était un bug ou voulu.

Où l'humain reste dans la boucle

L'humain dans la boucle ne veut pas dire qu'une personne lit chaque ligne de code.Cela veut dire qu'une personne garde la main sur les décisions que le code ne peut pas prendre seul.

Les outils de revue de code par IA aident pour la deuxième ligne : ils lisent un diff et signalent le code risqué.Ils regardent pourtant toujours le code, pas l'application en marche.L'exécution de bout en bout est la seule vérification qui regarde le produit.

Les tests de bout en bout pour les agents de codage IA avec GUI Test Studio

GUI Test Studio a été construit pour ce partage des rôles.Une personne enregistre le test ou le décrit, l'agent l'exécute et lit le verdict, le pipeline l'exécute à chaque build, et une modification de ce que le test attend n'est faite qu'avec l'accord d'une personne.

Un test qui ne dépend pas du code

Enregistrez une fois le parcours dans GUI Test Runner-Recorder, en cliquant et en tapant dans la vraie application, ou décrivez-le dans une consigne à Claude, à ChatGPT ou à un modèle d'IA local sur votre propre ordinateur, l'un des nôtres ou le vôtre.Dans les deux cas, le test vérifie l'écran.Une assertion visuelle compare l'image d'un élément, une assertion de texte lit ses mots, une assertion de disposition vérifie comment les éléments sont agencés.

Il n'y a aucun sélecteur à écrire et aucun code de test que l'agent pourrait réécrire.Le GTS Engine + AI trouve chaque élément par ce que l'application en dit, ses informations d'accessibilité, et à vue quand elle ne dit rien.Une classe renommée ou un composant réécrit ne casse pas le test.Quand un assistant crée un test pour vous, chaque assertion qu'il ajoute est essayée sur-le-champ et refusée si elle ne pouvait pas réussir à l'écran à l'instant même.

L'agent l'exécute et lit le verdict

GUI Test Studio est fourni avec un connecteur MCP, si bien que l'assistant qui écrit votre code peut aussi exécuter vos tests.Il fonctionne avec Claude Code, Claude Desktop, ChatGPT avec Codex et Copilot Chat dans VS Code, connectés en un clic, et avec tout autre assistant qui accepte un connecteur MCP.

Run the Checkout test and tell me what failed.

Une exécution échouée est expliquée à partir de son rapport, jamais par un nouvel enregistrement du test, sauf si vous le demandez.Par le connecteur, le test qui juge le changement de l'agent reste celui que vous avez approuvé jusqu'à ce que vous confirmiez une modification de ce test.

Sur chaque pull request, avec gtr-cli

gtr-cli exécute les mêmes tests depuis votre pipeline, sur une machine de build Windows, et répond comme un pipeline l'attend.Son code de sortie fait échouer le build, un fichier JUnit remplit l'onglet des tests, un fichier JSON est là pour un script ou un agent, et un résumé Markdown est prêt pour la pull request.Une exécution par gtr-cli ne modifie jamais le fichier de test.

gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
  --json results\run.json --summary results\summary.md --artifacts results\artifacts ^
  --jira on-failure

Avec --jira on-failure, un test échoué devient un ticket Jira avec les étapes pour reproduire et les images attendue et obtenue, et le même échec revu ajoute un commentaire au lieu d'un doublon.La même commande fonctionne dans GitHub Actions, GitLab, Azure DevOps, Jenkins et TeamCity : voir Exécuter des tests dans votre pipeline, et Exécutez vos tests de bout en bout à chaque build pour une configuration TeamCity pas à pas.

Un second regard, et le dernier mot à une personne

Chaque exécution se termine par un rapport de confiance qui dit, pour chaque assertion, si l'élément a été trouvé et s'il correspond à ce qui a été enregistré.Quand une assertion échoue sur les pixels, l'analyse intelligente par IA peut poser un second regard : elle ignore le bruit de rendu sans conséquence et attrape quand même les vraies régressions, comme un mot changé, un badge manquant ou un bouton devenu gris.Quand elle est activée, sa réponse est le verdict final de cette assertion, avec ce qui a changé en mots simples.Elle tourne dans le cloud avec votre propre clé OpenAI ou Anthropic, ou avec un modèle d'IA local sur votre propre ordinateur : l'un des nôtres, ou le vôtre.

Agrandir

Quand l'application a changé volontairement, une personne accepte le nouvel aspect dans le rapport et le sauvegarde, et le test l'attend désormais.Comment lire le rapport est expliqué dans Lire le rapport de confiance.

Ce guide est le côté pratique des tests.Pour tout le cycle du développement avec des agents IA, de la consigne au bug Jira que l'agent corrige, lisez Développement avec des agents IA (ADLC).

Questions

Claude, Cursor, GitHub Copilot, OpenAI Codex, ChatGPT, Devin, Playwright, Cypress, Selenium, Jira et TeamCity sont des marques de leurs propriétaires respectifs.