Sélecteurs stables et attente automatique dans les tests de bout en bout en navigateur

Objectif

Éliminer les deux causes dominantes d'instabilité des tests en navigateur : des sélecteurs qui se cassent lors de changements de balisage ou qui correspondent au mauvais élément, et des hypothèses de minutage qui échouent sur un exécuteur ou un réseau plus lent. La procédure générale pour les tests instables fait l'objet d'une entrée séparée ; celle-ci est spécifique aux suites en navigateur.

Prérequis

Un framework d'automatisation de navigateur avec localisateurs et attente automatique (Playwright, Cypress ou similaire) ; une application dont les contrôles ont des noms accessibles ; des données de test pouvant être créées par test afin que les pages démarrent dans un état connu.

Étapes

1. Localiser les éléments comme un utilisateur les perçoit. La documentation de Playwright recommande des localisateurs fondés sur le rôle (un bouton nommé « Sign in », un champ de texte libellé « Email ») et indique que CSS et XPath ne sont pas recommandés car le DOM change souvent ; les identifiants de test sont décrits comme l'option la plus résiliente mais non visible pour l'utilisateur, ce qui les rend adaptés aux contrôles sans nom accessible stable.
2. Faire en sorte que chaque localisateur se résolve en exactement un élément. Les localisateurs Playwright sont stricts et lèvent une erreur lorsque plusieurs éléments correspondent ; préférer filtrer sur le texte ou un conteneur plutôt que first() ou nth(), qui choisissent par position et suivent un DOM réordonné sans se plaindre.
3. Ne jamais mettre en pause. Les actions Playwright attendent des vérifications d'actionnabilité (visible, stable, reçoit les événements, activé, modifiable selon le cas) avant d'agir, et des assertions telles que toBeVisible ou toHaveText réessaient jusqu'à ce que la condition se vérifie ou que le délai expire. Cypress documente que les requêtes et assertions réessaient alors que la plupart des commandes telles que .click() ne le font pas, si bien qu'une assertion placée avant une action constitue le point de synchronisation.
4. Attendre des effets, pas du temps : après une soumission, vérifier l'URL résultante, le texte ou la réponse réseau avant de continuer.
5. Garder les tests indépendants : créer les données nécessaires via une API ou une amorce (seed), s'authentifier avec une session stockée plutôt que par le formulaire de connexion, et ne jamais dépendre de l'exécution préalable d'un autre test.
6. Traiter explicitement les animations et les superpositions : vérifier qu'une superposition a disparu avant de cliquer derrière elle. La vérification de stabilité de Playwright exige la même boîte englobante sur deux images d'animation consécutives.
7. N'utiliser les nouvelles tentatives automatiques que pendant le diagnostic, avec traces et vidéos collectées, et les retirer une fois la cause corrigée.

Résultat attendu

Les échecs reflètent de vraies régressions ; les tests survivent aux refactorisations de balisage qui conservent la structure accessible ; le temps d'exécution de la suite diminue car les pauses fixes ont disparu.

Limites et base de vérification

Les localisateurs fondés sur le rôle nécessitent un balisage accessible, ce qui constitue en soi une exigence produit. L'attente automatique ne peut pas aider une application qui affiche du contenu périmé puis le remplace plus tard ; de telles pages ont besoin d'un état de chargement explicite. Les délais d'expiration existent toujours et se déclenchent toujours sur un exécuteur d'intégration continue surchargé. Aucune mesure n'est revendiquée.