Comment Vérifier le Code Généré par l'IA Avant de le Fusionner

Le problème de relire un code qu'on n'a pas écrit

Un agent de codage IA peut produire une fonctionnalité fonctionnelle en quelques minutes. Le goulot d'étranglement s'est déplacé : la contrainte n'est plus la vitesse d'écriture du code, c'est le degré de confiance avec lequel quelqu'un peut affirmer que le code fait ce qu'il était censé faire. Relire attentivement un gros diff prend plus de temps que de le générer.

Les vérifications de type et les tests unitaires confirment que le code fait ce pour quoi il a été écrit. Ils ne peuvent pas vous dire si l'application déployée fonctionne toujours, parce qu'ils n'en ouvrent jamais une. C'est cet écart où vivent réellement les régressions générées par l'IA.

La boucle, en trois commandes

Installez le TestSprite CLI open source — gratuit, Apache-2.0, Node 20.19+, 22.13+, ou 24+ :

npm install -g @testsprite/testsprite-cli
testsprite setup

Puis la boucle. Décrivez le comportement que vous voulez garantir, exécutez-le dans un vrai navigateur, et lisez le verdict à partir du code de sortie :

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

Le lot de l'étape deux est la partie qui compte. Il contient l'étape en échec, ses étapes voisines, des captures d'écran, des instantanés du DOM, le code source du test, une hypothèse de cause profonde, et une cible de correction recommandée — le tout partageant un identifiant d'instantané unique. Le CLI refuse de combiner des données provenant de deux exécutions différentes, de sorte qu'un agent ne raisonne jamais sur un contexte assemblé à partir de deux états différents de l'application.

Pourquoi une suite durable bat une fenêtre de contexte plus grande

Chaque test qui réussit est mis en banque. La prochaine fois que l'agent touche à la base de code, cette exigence est toujours vérifiée — qu'elle soit ou non présente dans la conversation en cours.

C'est l'argument structurel en faveur de la vérification externe. Une fenêtre de contexte contient ce à quoi l'agent pense en ce moment. Une suite de tests contient chaque exigence que le projet a jamais correctement remplie, et continue de les maintenir à travers les sessions, à travers les agents, et à travers les mois où plus personne ne se souvient pourquoi tel cas limite particulier importait.

Configurez votre agent pour qu'il le fasse lui-même

Vous ne devriez pas avoir à relayer des commandes entre une page web et votre agent de codage. Une seule commande de configuration installe un fichier de compétence dans le dépôt décrivant la boucle sous la forme qu'un agent consomme réellement :

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

Les environnements pris en charge sont claude, codex, cursor, cline, antigravity, kiro, windsurf, et copilot. L'installation est purement locale. Après cela, l'agent sait comment créer, exécuter, et trier les tests sans qu'on le lui redemande à chaque session.

Avant de consacrer un tour à une commande qui échouera pour des raisons environnementales, vérifiez l'environnement :

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

Que vérifier en premier

Tout ne mérite pas un test de bout en bout. Dans une base de code changeant rapidement sous un agent IA, la couverture à plus forte valeur est restreinte :

1. Les flux qui produisent du revenu. Inscription, paiement, et facturation. Une régression ici coûte de l'argent immédiatement et est fréquemment invisible dans les tests unitaires.

2. Tout ce qui implique l'authentification. La gestion de session, les redirections après connexion, et les limites de permission sont les endroits où un refactoring d'apparence plausible fait le plus de dégâts.

3. Les formulaires et la validation. Peu coûteux à décrire, et disproportionnellement susceptibles de se casser lorsqu'une bibliothèque de composants est mise à jour ou qu'un champ est renommé.

4. Les trois derniers bugs que vous avez livrés. Un test de non-régression écrit après une correction est le test au plus haut rendement dans n'importe quelle suite.

Si vous préférez que le premier ensemble soit proposé pour vous, l'exploration peut en rédiger un brouillon. Les propositions sont mises en attente de revue et rien n'est écrit sur votre disque tant que vous n'avez pas accepté :

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

Rendre la vérification obligatoire

Une étape de vérification qui ne s'exécute que lorsque quelqu'un pense à la lancer n'est pas une vérification. Mettez-la dans la CI :

testsprite ci init github

Cela échafaude .github/workflows/testsprite.yml en utilisant TestSprite/testsprite-action@v1, qui annote l'onglet des checks de la PR avec une erreur par échec, ajoute un tableau de résultats au résumé du job, télécharge un rapport JUnit, et — surtout — fait échouer le job en cas d'exécution partielle plutôt que de le signaler comme vert.

C'est le chemin où votre workflow pilote l'exécution. TestSprite s'installe aussi comme une GitHub App qui écoute les événements de déploiement que votre pipeline produit déjà et republie les résultats sur la pull request, ce qui ne nécessite aucun fichier de workflow ni aucune modification de dépôt.

Dans n'importe quel autre système CI, le CLI n'a besoin que d'une clé API dans l'environnement :

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

Des codes de sortie sur lesquels s'appuyer

Les codes 129, 130, et 143 signifient que le processus a été interrompu par un signal (128 plus le numéro du signal), pas qu'un test a échoué — cela vaut la peine de le distinguer avant de signaler une exécution comme cassée.

Foire aux questions