Corrigez les tests E2E en échec en observant le vrai navigateur

## Définissez avant le test à quoi ressemble la réussite dans le navigateur Avant d'exécuter un test de bout en bout, traduisez le comportement demandé en conditions observables dans le navigateur réel. Consignez l'adresse ou la route de départ, l'état requis du compte ou des données de test, les dimensions de la fenêtre d'affichage lorsqu'elles sont pertinentes, les actions de l'utilisateur et le résultat visible exact qui constitue une réussite. Incluez l'état d'accessibilité, la navigation, l'état persistant et le contenu issu du réseau lorsqu'ils font partie du comportement. - Préférez les rôles et libellés stables destinés aux utilisateurs, ainsi que les identifiants de test dédiés, aux classes de style ou à la position dans le DOM. - Distinguez l'interface de l'outil d'exécution des tests de l'application testée ; les preuves provenant de l'une ne décrivent pas automatiquement l'autre. - Définissez à la fois des preuves positives, comme une confirmation visible ou une valeur modifiée, et des preuves négatives, comme l'absence d'une bannière d'erreur. - Exprimez les attentes temporelles au moyen d'une condition de disponibilité observable, et non d'un délai arbitraire. N'affaiblissez pas une vérification uniquement pour faire réussir le test. Si le comportement attendu est ambigu, arrêtez-vous et clarifiez le contrat d'acceptation avant de modifier le test ou le code du produit. ## Lancez le test dans un vrai navigateur et gardez captures d’écran et journaux Lancez le scénario de bout en bout pertinent le plus restreint dans un véritable navigateur pris en charge, en suivant le parcours normal de l'application. Rendez la configuration, les données de test, l'état d'authentification, les dimensions d'affichage et les paramètres d'activation des fonctionnalités suffisamment explicites pour que l'exécution soit reproductible. Si un mode avec interface graphique ou un mode de débogage est disponible, utilisez-le lorsque l'état visuel ou l'interaction avec le navigateur est déterminant. En cas d'échec, recueillez les preuves avant toute modification : - le scénario en échec et la vérification ou la commande exacte ; - une capture d'écran ou un instantané du navigateur au moment de l'échec ; - le DOM de l'application autour de l'élément ciblé, y compris son nom accessible et son état ; - les erreurs pertinentes de la console du navigateur et les requêtes réseau échouées ou inattendues ; - l'adresse actuelle, les redirections, les indicateurs de chargement et les messages d'erreur visibles dans l'application ; - les horodatages ou identifiants d'exécution nécessaires pour établir une correspondance avec les journaux du serveur lorsqu'ils sont disponibles. Inspectez de façon ciblée au lieu de recueillir des états sans rapport. Si nécessaire, reproduisez une fois dans les mêmes conditions pour distinguer un échec stable d'un échec transitoire, mais ne lancez pas une boucle de nouvelles tentatives sans limite. ## Classez la cause de l’échec : test, code ou environnement Classez l'échec observé comme provenant du test, de l'implémentation ou de l'environnement. Cette classification doit être étayée par des preuves issues du navigateur et, lorsque cela est nécessaire, par l'inspection minimale du code source ou des journaux pertinents. - Cause liée au test : le produit se comporte conformément au contrat d'acceptation, mais le test utilise un sélecteur obsolète, une vérification incorrecte, des données de test non valides, une mauvaise séquence ou une condition de disponibilité insuffisante. - Cause liée à l'implémentation : le comportement visible par l'utilisateur enfreint le contrat d'acceptation, par exemple une commande qui ne répond pas, un état ou une navigation incorrects, une régression d'accessibilité ou une requête de l'application qui échoue à cause du code du produit. - Cause liée à l'environnement : le test et l'implémentation peuvent être corrects, mais un prérequis manque ou fonctionne mal, par exemple un service indisponible, des identifiants d'accès non valides, un navigateur incompatible, des données initiales absentes, une mauvaise configuration ou une ressource épuisée. Lorsque les preuves sont contradictoires, formulez des hypothèses concurrentes et exécutez une seule vérification discriminante à la fois. Ne classez pas systématiquement chaque dépassement de délai comme un problème de test et ne modifiez pas le code du produit uniquement parce qu'un test a échoué. Maintenez la classification comme provisoire jusqu'à ce que les preuves excluent les possibilités les plus proches. ## Appliquez la plus petite correction sans affaiblir les assertions Choisissez la correction qui traite la cause classée sans procéder à une vaste refactorisation. Préservez le contrat d'acceptation et le comportement existant de l'utilisateur en dehors du parcours en échec. - Pour une cause liée au test, mettez à jour uniquement le sélecteur, la vérification, les données de test, la séquence d'actions ou la condition de disponibilité qui contredit l'état observé du navigateur. - Pour une cause liée à l'implémentation, ajoutez ou conservez si possible un test de régression en échec, puis modifiez la plus petite portion de logique du produit nécessaire pour rétablir le comportement spécifié. - Pour une cause liée à l'environnement, réparez ou documentez le prérequis manquant ; ne le dissimulez pas derrière des attentes plus longues, des vérifications désactivées ou des nouvelles tentatives systématiques. - Préférez les signaux déterministes, comme un état de disponibilité visible, des requêtes terminées ou un état stable, aux pauses fixes. - Veillez à ce que les changements destinés à faciliter les tests restent neutres pour l'utilisateur : ajoutez des identifiants stables ou des libellés accessibles sans coupler les tests à une disposition visuelle fortuite. Avant de modifier des ressources protégées, générées, de production, destructives ou contenant des identifiants d'accès, arrêtez-vous et obtenez l'autorisation requise. N'exposez jamais de secrets dans les tests, journaux, captures d'écran, données de test ou rapports. ## Relancez le même scénario et arrêtez-vous si les échecs se répètent Après la correction, réexécutez exactement le scénario en échec avec les mêmes conditions de navigateur et le même contrat d'acceptation. Une réussite ne compte que si le navigateur atteint visiblement l'état de réussite défini et si l'outil d'exécution ne signale aucun échec caché. Confirmez que les preuves de la console et du réseau ne montrent plus l'erreur causale lorsque ces signaux ont servi au diagnostic. Exécutez ensuite le plus petit périmètre de régression directement affecté : le scénario environnant, le fichier de fonctionnalité ou le groupe de tests étroitement lié. N'étendez pas la vérification à une suite complète sans rapport, sauf si la modification a un impact étendu ou si l'utilisateur le demande explicitement. Si la nouvelle exécution échoue différemment, revenez à la collecte des preuves et à la classification au lieu d'empiler des modifications spéculatives. Limitez les tentatives répétées. Après deux corrections inefficaces fondées sur la même approche, réévaluez le diagnostic et choisissez une autre vérification discriminante. Après trois échecs consécutifs sans nouvelle preuve, arrêtez-vous et signalez le blocage au lieu de continuer à modifier le code. ## Annoncez d’abord réussi, échoué ou bloqué, avec les preuves Ne concluez à une réussite que lorsque le contrat d'acceptation original observable dans le navigateur est respecté, que le périmètre de régression directement affecté est validé et qu'aucune erreur causale pertinente ne subsiste. Arrêtez-vous également lorsque la progression exige une autorisation manquante, des identifiants d'accès, une infrastructure indisponible, une action destructive ou une décision relative au produit qui ne peut être déduite en toute sécurité. Présentez le résultat avec suffisamment de preuves pour qu'une autre personne puisse le vérifier : - le scénario et les conditions de navigateur utilisés ; - l'échec observé et sa classification ; - les preuves qui ont étayé cette classification ; - la modification minimale effectuée ou le prérequis non résolu ; - les nouvelles exécutions exactes et leurs résultats ; - le risque restant, les vérifications plus larges omises et la prochaine action requise. Commencez par indiquer réussite, échec ou blocage. Ne prétendez pas que le travail est terminé à partir de la seule inspection du code, d'un test unitaire réussi ou d'un DOM simulé lorsque la condition de réussite dépend d'un navigateur réel.