Là où les tests de développement web par IA doivent chercher
| L'état entre les étapes | Un formulaire est envoyé et la liste qui se trouve derrière ne se rafraîchit pas. Un filtre persiste jusque dans un écran où il n'a aucun sens. |
| Le timing | Un rendu avant les données, ou une requête qui aboutit après la disparition du composant. |
| Le deuxième utilisateur | Propriété et visibilité supposées à partir de la session qui a servi à construire. |
Aucun de ces problèmes n'apparaît dans un diff, et c'est pourquoi relire plus vite n'aide en rien. Ils apparaissent en trente secondes d'utilisation de l'application en fonctionnement, et c'est donc là que la vérification doit avoir lieu.
Pourquoi les tests écrits par l'agent ne referment pas la boucle
Les tests générés en même temps que l'implémentation partagent ses hypothèses. Si le code part du principe qu'un endpoint renvoie un tableau vide plutôt qu'une 404, le test affirme la même chose et passe. Vous obtenez de la couverture, et aucun signal indépendant.
La vérification qui referme la boucle doit éprouver le produit déployé au regard du comportement attendu, et non de l'idée que le code se fait de lui-même.
Assez rapide pour être vraiment utilisé
Une étape de vérification plus longue que la construction de la fonctionnalité sera ignorée, et à juste titre. Trois choses la gardent proportionnée : couvrir des parcours plutôt que des écrans, garder des chaînes courtes, et s'exécuter sur la pull request plutôt qu'à chaque sauvegarde.
Garder la boucle assez courte pour qu'elle serve
Une étape de vérification qui paraît lente finit par être ignorée, et cet abandon est rationnel : le rythme compte autant que la couverture.
Trois choses la gardent proportionnée. Couvrez des parcours plutôt que des écrans, parce qu'un parcours représente une vérification là où un écran en représente cinq. Limitez chaque parcours au chemin le plus court qui détecterait encore une vraie casse, soit généralement trois ou quatre étapes plutôt que dix. Et lancez la suite étendue sur la pull request, en gardant une ou deux vérifications assez rapides pour tourner pendant le travail lui-même.
C'est cette dernière séparation que l'on oublie. La vérification que vous lancez pendant le développement et celle qui protège la fusion n'ont pas le même rôle ; vouloir couvrir les deux avec une seule suite la rend soit trop lente pour être lancée souvent, soit trop légère pour être fiable.
L'intégrer à la boucle
L'installation ajoute la compétence de vérification à l'agent de code, pour que le contrôle se fasse là où se fait le travail, et non comme une corvée à part.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs se trouve dans le dépôt CLI.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Elle écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.
GitHub Actions place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal.
Ce que TestSprite vérifie et que l'agent ne peut pas vérifier
L'application déployée, confrontée à ce que vous avez annoncé comme comportement attendu plutôt qu'aux hypothèses du code. C'est cette indépendance qui fait tout : des tests écrits à côté de l'implémentation partagent ses hypothèses, donc ils lui donnent raison, y compris là où tous les deux se trompent.
L'installation ajoute la compétence de vérification à votre agent de code, pour que le contrôle fasse partie de la modification elle-même. Les étapes sont des intentions plutôt que des sélecteurs, et un échec revient sous la forme d'un ensemble unique sur lequel l'agent peut agir, ce qui maintient le correctif dans la même boucle que la modification.
Vous obtenez ainsi des défaillances d'état, de timing et de deuxième utilisateur détectées avant la fusion plutôt que par un utilisateur, sans étape de vérification plus longue que la fonctionnalité elle-même.
Est-ce que cela ralentit le développement ?
Moins que le débogage que cela évite. La comparaison ne se fait pas avec un coût nul, mais avec la découverte du même défaut après la mise en production.
L'agent peut-il tester son propre travail ?
Il peut exécuter les vérifications. Les vérifications elles-mêmes doivent découler du comportement attendu et non de l'implémentation, sinon vous corrigez votre propre copie.
Et les tests qu'il a générés ?
Gardez-les pour la couverture et ne les considérez pas comme une vérification indépendante. Ils donnent raison au code par construction.
Quelle couverture avant de livrer ?
Les parcours dont la casse vous embarrasserait, plus tout ce qui touche à l'argent ou aux permissions. Élargissez à partir d'incidents réels.
Est-ce que cela fonctionne en développement local ?
Les exécutions frontend peuvent atteindre une application sur votre machine via un tunnel : la vérification est donc disponible avant tout déploiement.
La construction a accéléré. Le contrôle doit rattraper son retard.
Les tests de développement web par IA exigent une vérification indépendante face au produit en fonctionnement, parce que des tests écrits à côté de l'implémentation partagent ses hypothèses. Couvrez des parcours, gardez l'effort proportionné, et lancez la vérification sur la pull request.