Un autre navigateur ne signifie pas un autre compte

Deux tests fictifs tournent en même temps. Le premier attend le fuseau UTC. Le second enregistre "Europe/Riga". Chacun a un nouveau contexte de navigateur, mais ils utilisent le même compte. Le premier échoue parce que les données du serveur ont changé, malgré la séparation des cookies.

Cette distinction est importante lorsqu'un agent génère plus de couverture que votre ancienne suite. L'exécution parallèle peut révéler des hypothèses d'état partagé qui étaient masquées lorsque les tests étaient exécutés les uns après les autres. L'artefact pratique est une carte de propriété : quel test peut écrire quel compte et quel enregistrement, et quand cet état est réinitialisé.

Dessinez les deux limites séparément

Le guide d'authentification de Playwright explique l'isolation du contexte du navigateur et le chargement de l'état authentifié. Il avertit également que les tests qui modifient l'état côté serveur doivent utiliser des comptes différents lorsqu'une utilisation simultanée affecterait un autre test. Un contexte est une limite client. Un espace de noms de compte, de locataire ou d'enregistrement constitue une limite d'application. Ni l'un ni l'autre ne remplace l'autre.

Énumérez les deux en revue. Un test généré doit identifier le contexte qu'il utilise et les données qu'il peut modifier. S'il ne lit que du contenu immuable, partager un compte peut être raisonnable. S'il modifie les paramètres, crée des commandes ou modifie un document partagé, vérifiez la propriété du compte et de l'enregistrement avant d'augmenter les travailleurs parallèles.

Choisissez la plus petite unité de propriété utile

Le guide Playwright documente un compte par travailleur parallèle pour les tests qui modifient l'état côté serveur. Cela peut réduire les interférences entre les travailleurs. Cela ne signifie pas que chaque test effectué chez un travailleur peut laisser derrière lui des modifications arbitraires. Réinitialisez ou initialisez l'état dont chaque test a besoin et rendez le nettoyage explicite.

Parfois, l'unité la plus sûre est un enregistrement unique par test plutôt qu'un compte par test. Pour une liste de tâches appartenant à une équipe, des comptes distincts peuvent toujours écrire la même liste partagée. Pour un flux de paiement, un espace de noms de panier ou de commande unique peut être nécessaire. Choisissez l'unité à partir des règles de partage réelles du produit, et non à partir du nom de l'API du navigateur.

Un contrat de données qu'un agent peut suivre

Écrivez quatre champs à côté de chaque scénario : espace de noms du propriétaire, état de configuration, écritures autorisées et comportement de nettoyage. Un exemple de contrat peut réserver un utilisateur intermédiaire pour un travailleur, créer un panier vide avant le test, permettre de créer uniquement des commandes synthétiques et supprimer ces commandes après avoir conservé la preuve d'échec. Indiquez ce qui se passe lorsque le nettoyage échoue ; sinon, la prochaine exécution hérite d'un mystère.

Gardez la configuration indépendante du succès d'un autre test. Les appareils Playwright fournissent un cycle de vie structuré pour la préparation et la publication des ressources de test. Utilisez ce cycle de vie pour rendre la propriété lisible, et non pour cacher un compte partagé global derrière un nom d'appareil pratique. Le réviseur devrait être en mesure de trouver à qui appartient chaque ressource mutable.

Une équipe d'assurance qualité peut utiliser cette carte pour passer moins de temps à rechercher les échecs accidentels des tests croisés. Une équipe sans contrôle qualité peut commencer avec un flux critique et un pool de comptes intermédiaires limité. Ni l'un ni l'autre n'a besoin de créer un environnement immense avant de mesurer si le premier flux est utile.

L'état d'authentification est un fichier secret

Playwright prévient que l'état enregistré du navigateur peut contenir des cookies et des en-têtes pouvant usurper l'identité d'un compte. Son guide déconseille de confier ces fichiers dans des référentiels, y compris privés. Traitez-les comme des informations d'identification : conservez-les hors des archives sources, restreignez l'accès et régénérez-les le cas échéant.

Ne donnez jamais de session de production à un agent exploratoire simplement parce que la configuration de la connexion ne vous semble pas pratique. Utilisez des comptes intermédiaires avec les autorisations nécessaires pour le scénario. Un navigateur distinct portant un cookie d'administrateur est toujours un administrateur.

Compter les faux échecs comme du vrai travail

Suivez les échecs causés par l'état partagé séparément des régressions de produits. Incluez les minutes passées à réactualiser les comptes et à enquêter sur les interférences dans les coûts de réparation d'un pilote d'automatisation. Un plus grand nombre de tests générés peuvent augmenter la couverture, mais ils peuvent également accroître les conflits si la propriété n'est pas claire. Les économies surviennent lorsque la couverture utile et les données prévisibles réduisent le travail répété, et non lorsque le nombre de tests augmente à lui seul.