Fixtures et isolation pour l'automatisation du navigateur
Concevez des fixtures avec une propriété claire, un état isolé, des workers parallèles sûrs et un nettoyage déterministe.
Vous voulez la documentation structurée pour Démarrage ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Une automatisation fiable commence par une fixture qui possède un petit ensemble déclaré de ressources. Elle peut créer un contexte, une page, un répertoire temporaire et des données synthétiques. Elle doit aussi indiquer qui ferme chaque ressource et quel résultat reste visible lorsqu'une assertion échoue.
La règle est simple : chaque test reçoit des entrées connues, observe un résultat limité et libère ce qu'il a créé. Playwright décrit ce modèle avec ses fixtures de test, tandis que Selenium décrit l'indépendance dans ses pratiques de test. Consultez aussi le cycle de vie Playwright pour séparer la limite de la fixture de la propriété d'une session distante.
Écrire le contrat de la fixture
Le contrat nomme les entrées, les sorties et le propriétaire. Les entrées peuvent être la version du navigateur, les options du contexte, un compte synthétique autorisé, un enregistrement préparé et un dossier propre au worker. Les sorties restent courtes : catégorie du résultat, assertion visible et reçu de nettoyage. Un enregistrement distant appartient à l'application, pas à la fixture.
Gardez la préparation près de la portée qui l'utilise. Un contexte par test convient quand chaque cas doit démarrer proprement. Un navigateur par worker peut éviter des lancements répétés si chaque worker crée son contexte et ses fichiers. Une page globale conserve parfois cookies, service workers et mémoire au-delà du test. La portée doit apparaître dans le nom de la fixture.
Séparez la propriété du navigateur et celle de l'application. La fixture peut ouvrir une page et utiliser une connexion approuvée, mais l'application définit la déconnexion et le service définit la conservation des données. Fermer un contexte libère l'état géré par le navigateur; cela ne révoque pas une autre session et n'annule pas une mutation distante.
Notez le scénario, la version, la portée, l'étiquette synthétique et le nettoyage. N'écrivez pas de cookies, de jetons, de réponses complètes ou de texte personnel dans les journaux ordinaires. Le mainteneur doit comprendre le résultat sans ouvrir toute la session.
Choisir une portée sans partage accidentel
Processus, navigateur, contexte, page, worker et test sont des portées différentes. Un navigateur héberge plusieurs contextes, un contexte regroupe pages et stockage, une page représente un onglet. Passez le contexte ou la page aux helpers au lieu de chercher une page globale.
Utilisez un contexte neuf lorsque les cookies, le stockage, les permissions, les service workers ou un état d'origine propre sont importants. L'isolation évite de mélanger l'état du navigateur, mais ne crée pas une sandbox système. L'application peut toujours écrire dans des services partagés et le runner peut partager des fichiers. Chaque ressource externe a besoin d'un propriétaire.
Un snapshot storageState est une entrée qui a un cycle de vie, pas une sauvegarde universelle. Il peut contenir cookies et stockage d'origine, mais pas la mémoire, les files de workers, les identifiants natifs ni toute session serveur. Traitez-le comme un artefact synthétique sensible. Copiez une base en lecture seule vers une route propre et invalidez tout fichier incomplet.
La même règle vaut pour les profils Selenium. Répertoire de profil, driver et binaire forment une entrée de compatibilité. Donnez à chaque session un chemin propre et fermez le driver selon son cycle normal. Le guide d'intégration des profils Selenium précise cette propriété. Un profil reproduit des entrées déclarées, pas une décision de service.
Préparer un état sûr pour les workers parallèles
Les workers parallèles échouent lorsqu'ils partagent un état mutable : fichier storageState, dossier de téléchargement, compte synthétique ou nom de capture. Un fichier peut être valide mais appartenir au mauvais worker. Donnez à chaque worker une étiquette de scénario et un répertoire privé sous la racine d'artefacts approuvée.
Chargez une base en lecture seule et écrivez le nouvel état à côté. Une fixture de connexion peut renouveler un état synthétique et le sauvegarder avec worker et tentative. Un résultat partiel doit être isolé ou marqué invalide. Ne remplacez jamais une base qu'un autre contexte lit.
Un navigateur propre ne supprime pas une course dans le service. Préférez des enregistrements synthétiques indépendants, une remise à zéro documentée ou un cas en lecture seule. Si une mutation doit être partagée, rendez cette opération séquentielle et documentez son propriétaire. Un délai arbitraire ne répare pas une course.
Les observations de chaque worker restent limitées. Gardez une catégorie d'URL, un statut visible et un nom d'erreur court. Une trace ou une capture autorisée doit utiliser un chemin propre au worker et la politique de conservation habituelle. Un fichier portant le bon nom mais le contenu d'un autre worker est un échec de fixture.
Rendre le nettoyage déterministe
Le nettoyage fait partie de la correction. Placez-le dans finally après réussite, assertion, délai expiré ou erreur de préparation. Fermez les pages à durée courte puis le contexte qui les possède. Le propriétaire d'un navigateur partagé ferme le navigateur quand tous les contextes ont fini; le contrat d'exécution décide si un autre composant ne fait que se déconnecter.
Conservez la première erreur si le nettoyage échoue aussi. Sauvegardez l'erreur du scénario, tentez la fermeture puis ajoutez l'erreur de nettoyage. Remplacer l'assertion par l'erreur de fermeture rend le diagnostic incomplet. Ignorer la fermeture laisse une session ouverte avec un résultat trompeur.
Fermez téléchargements, enregistrements, descripteurs et dossiers temporaires créés par le test selon leurs APIs. Fermer le contexte ne supprime pas un fichier déjà copié dans un stockage d'artefacts et n'annule pas une mutation envoyée au serveur. Effectuez la déconnexion applicative avant la fermeture quand le contrat le demande.
Le nettoyage doit supporter un second appel. Un délai peut laisser une page partiellement créée et un runner peut appeler un hook après la fixture. Vérifiez le handle puis fermez-le si la fixture en est toujours propriétaire. Ne fermez pas un autre contexte au nom ressemblant.
Coordonner tentatives et preuves
Une tentative est une nouvelle exécution, pas la continuation d'une page inconnue. Décidez si l'action était en lecture et si l'application fournit une vérification d'idempotence ou de statut. Si une nouvelle tentative est autorisée, fermez l'ancien contexte, créez-en un nouveau avec les mêmes entrées synthétiques et notez le numéro. Un succès ultérieur ne prouve pas que le premier essai était sans effet.
Classez séparément préparation, application, assertion et infrastructure. Un état absent concerne la fixture; une requête rejetée concerne l'application ou le service; une déconnexion du driver concerne l'infrastructure. Un délai manquant identifie le signal visible absent, mais pas la raison de la réponse distante.
Le diagnostic nomme la condition au lieu de copier la session. Incluez scénario, versions, catégorie d'URL, repère attendu et état du nettoyage. Une capture synthétique peut aider, mais elle peut aussi contenir des secrets. Limitez l'accès et la durée; supprimer plus tard ne rappelle pas une copie déjà partagée.
Répétez le chemin d'échec avec une page synthétique qui ne fournit pas un signal de disponibilité. Le résultat attendu est une erreur bornée qui nomme ce signal et un reçu de nettoyage. Il ne faut pas interroger des origines étrangères ni élargir la collecte pour obtenir un succès.
Examiner la frontière applicative
L'isolation du navigateur donne un point de départ connu. Elle ne garantit pas l'indépendance de deux sessions serveur, l'acceptation d'un cookie ou le nettoyage applicatif. Vérifiez ce que le test peut observer : état local absent, route protégée et requête suivante conforme au contrat. Demandez au propriétaire du service les preuves hors navigateur.
Traitez un changement de compte comme une transition. Utilisez la déconnexion prévue, effacez seulement l'état documenté et créez le contexte suivant avec son propre état approuvé. Vérifiez un titre de compte visible ou une réponse d'accès. Un onglet, un worker, une file hors ligne ou un service worker peut encore afficher l'ancien état.
Gardez la fixture éloignée de la découverte de comptes et de la collecte de signaux privés. Un test autorisé possède un compte connu, une route déclarée et un résultat observable. Si une dépendance manque, notez cette catégorie et arrêtez-vous à la limite approuvée.
Après une mise à jour du navigateur ou de l'application, répétez contexte neuf, chargement et expiration de l'état, changement de compte, activité des workers, sorties parallèles et fermeture après erreur. Comparez le résultat visible et gardez les versions testées.
Capacité et limite de BotBrowser
BotBrowser fournit des BrowserContexts isolés avec cookies, stockage et état de session séparés. Une fixture autorisée peut ainsi répéter un scénario synthétique et vérifier qu'un nouveau contexte n'hérite pas de l'état local. La documentation BotBrowser sur l'isolation multi-compte décrit cette frontière du navigateur. BotBrowser ne remplace pas la gestion du cycle de vie Playwright ou Selenium, le nettoyage applicatif, l'invalidation d'une session serveur ou la gestion des secrets. Il ne garantit pas l'acceptation d'un cookie expiré, ne supprime pas une file du worker de service et n'efface pas un enregistrement fournisseur. Le propriétaire de la fixture garde ces responsabilités.
Utilisez cette capacité comme une entrée déclarée, pas comme une preuve distante. Notez version, but du contexte, source de l'état, étiquette du worker, nettoyage attendu et résultat observé. Gardez la limite dans le même reçu pour ne pas confondre un contexte local propre avec une suppression serveur.
Une revue pratique demande si chaque test possède son état mutable, si un worker peut écraser les fichiers d'un autre, si chaque échec atteint le même nettoyage et si le résultat précise ce qui n'a pas été observé. Ces réponses rendent la fixture maintenable lorsque le navigateur ou le framework évolue.
Lorsqu'un test utilise une réponse préparée, gardez la propriété de ses entrées et sorties. Le simulateur appartient au scénario, utilise des données synthétiques et réinitialise son état avec le contexte. Une réponse préparée ne prouve pas que le service réel conserve les mêmes données.
Le répertoire d'artefacts a aussi un propriétaire. Le worker écrit son résultat, mais CI décide qui peut le lire et quand il expire. Séparez le reçu court de la capture ou de la trace plus sensible pour qu'une revue n'ouvre pas un contenu inutile.
Une correction de fixture doit traiter la cause, pas seulement le symptôme. Si deux cas partagent par erreur un enregistrement, séparez-les ou définissez l'opération commune. Si le nettoyage échoue, gardez l'erreur dans la sortie et laissez le propriétaire du runner la traiter.
La documentation du scénario doit correspondre au code exécuté. Revoyez la portée quand le navigateur, le framework, le schéma d'état ou le service change. Un contrat court et actuel empêche une future fixture d'utiliser un chemin temporaire comme ressource commune.
Avant d'intégrer une modification, exécutez un cas avec contexte vierge, un cas avec état expiré et un cas qui force un échec de nettoyage avec le même reçu. Comparez l'étiquette du worker, la portée de la ressource, l'assertion visible et l'état final.
Gardez les entrées synthétiques et ne partagez que le reçu court. Si le comportement du serveur diverge, transmettez l'identifiant de requête au propriétaire de l'application; fermer le contexte ne prouve pas une suppression distante.
BotBrowser peut fournir une configuration de navigateur cohérente à chaque contexte de test; BotBrowser ne supprime pas les données que l'application conserve dans ses propres services.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.