Une coche verte ne prouve pas que le test est juste
Les agents IA écrivent des tests de bout en bout. Mais un message de succès ne prouve pas que les données ont été enregistrées. Vérifiez le résultat par une voie indépendante.
Édition traduite. Les identifiants techniques restent sous leur forme originale.
Le test clique sur "Envoyer". Une notification affiche "Enregistré". Le test vérifie ce message et passe. Trois semaines plus tard, un utilisateur signale que ses réglages n'ont jamais été conservés. Cet exemple est fictif, pas le récit d'un incident réel.
Rien dans cette histoire n'est nouveau et rien dans celle-ci ne nécessite l'IA. C'est la manière standard dont se déroulent les tests de bout en bout : l'assertion surveille l'interface utilisateur, et l'interface utilisateur est la chose testée. Lorsqu'un agent IA écrit les tests, le même mode de défaillance arrive à l'échelle industrielle, car l'agent apprend également quoi affirmer en observant l'interface.
Le problème de l'oracle, en un paragraphe
Chaque test comporte deux moitiés. La première moitié fait quelque chose. La seconde mi-temps décide si le résultat est bon. Cette seconde moitié est l'oracle, et c'est la moitié qui compte. Un oracle faible vérifie le signal visible le plus proche : un notification, un arrêt de la roulette, un changement d'URL. Un oracle puissant vérifie le résultat dans une direction indépendante : l'enregistrement dans la base de données, la réponse de l'API appelée par la page, l'état après un nouveau rechargement.
Le propre guide des meilleures pratiques de Playwright fait valoir le point adjacent concernant les actions : les tests doivent vérifier le comportement que l'utilisateur final peut voir et éviter le couplage avec des détails d'implémentation tels que les classes CSS. Le même principe appliqué aux assertions vous donne la règle pour l'ère de l'IA. Affirmez le résultat qu'un utilisateur vérifierait, via un chemin que le bogue ne peut pas simuler.
Pourquoi les tests écrits par l'IA dérivent vers des oracles faibles
Un agent qui explore votre application et écrit des tests apprend l'application à partir de sa surface. Il clique, il surveille ce qui change et il code exactement cela : cliquez sur ceci, puis cela change. Un notification est un signal pratique et d'apparence déterministe, comme l'affirme l'agent sur le notification. L'agent n'est pas négligent. Il n'a tout simplement pas accès à votre intention, uniquement à vos pixels.
L'attente automatique de Playwright rend cela plus sûr qu'il ne l'est. Les contrôles d'action confirment qu'un élément est visible, stable et reçoit des événements avant l'arrivée du clic. Les assertions à nouvelle tentative automatique attendent la condition attendue. Les deux réduisent les pannes liées au timing. Ni l'un ni l'autre ne demande si la condition était la bonne. Un test peut être parfaitement stable et complètement faux.
Trois mises à niveau d'Oracle qui fonctionnent aujourd'hui
Recharger et lire. Après la sauvegarde, naviguez vers l'arrière et vers l'arrière, ou rechargez et affirmez que la valeur est toujours là. Cela vérifie la persistance de la même manière qu'un utilisateur remarquerait son absence.
Affirmez une couche vers le bas. Le dramaturge peut attendre la réponse du réseau dont dépend l'interface utilisateur. Associez l'assertion d'interface utilisateur à expect(response).toBeOK() sur l'appel d'API qui enregistre réellement, ou interrogez l'API directement après le flux d'interface utilisateur et comparez la valeur stockée.
Vérifiez l'effet secondaire hors bande. Pour une inscription, indiquez-le sur la boîte d'envoi, le journal d'audit ou la liste des administrateurs, et non sur la bannière de bienvenue. La bannière est conçue pour apparaître ; le dossier n'existe que si le système a fonctionné.
La question de révision qui change tout
Si vous laissez les agents rédiger des tests et que des humains les révisent, consacrez du temps de révision à une question par test : qu'est-ce que cela affirme et pourrait-il réussir tant que la fonctionnalité est cassée ? Revoir le chemin heureux, c'est lire le test. Examiner l'oracle, c'est tester le test.
C'est aussi la manière honnête d'utiliser un outil comme AnyTest. Ses agents explorent votre application à partir d'une URL, créent des tests de bout en bout et les soumettent à votre examen. La surface de révision montre chaque étape et son résultat. Bien utilisé, cet examen est l'endroit où se produit la vérification Oracle : non pas "l'agent a-t-il cliqué sur les bonnes choses" mais "le test qu'il a écrit a-t-il prouvé quelque chose". Le propre matériel du vendeur indique que les humains décident toujours. C'est la décision qui compte.
Une coche verte vous indique que le test a été exécuté. Cela ne vous dit jamais que le test était correct.
Questions courantes
Qu'est-ce qu'un oracle de test ?
La partie d'un test qui décide de la réussite ou de l'échec. Une vérification sur un message de réussite est un oracle faible. Une assertion sur un état vérifié de manière indépendante, comme les données après un rechargement ou une requête API, est forte.
Un test réussi de bout en bout prouve-t-il que la fonctionnalité fonctionne ?
Non. Cela prouve que les conditions spécifiques affirmées par le test étaient vraies. Si l'assertion surveille uniquement l'interface utilisateur, la fonctionnalité peut être interrompue en dessous tandis que le test reste vert.
Comment auditer les tests rédigés par un agent IA ?
Pour chaque test, demandez ce qu'il affirme et s'il pourrait réussir alors que la fonctionnalité est cassée. Préférez les tests qui vérifient l'état persistant via un deuxième chemin : rechargement, requête API ou enregistrement hors bande.