Cycle de vie et état de stockage de BrowserContext avec Playwright
Créer des contextes isolés, réutiliser un état autorisé et fermer chaque test de façon 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.
Le cycle en bref
Playwright utilise BrowserContext comme environnement de navigation isolé. Chaque contexte possède ses cookies, son stockage web, ses permissions et son état de service worker. Créez-le avec des entrées connues, exécutez un parcours autorisé, notez un résultat minimal, puis fermez-le dans le même périmètre. Ainsi une nouvelle exécution ne récupère pas silencieusement l'état de la précédente.
La documentation BrowserContext de Playwright décrit l'indépendance des contextes. La documentation d'authentification explique le chargement d'un état authentifié. La documentation BotBrowser sur l'isolation multi-compte décrit une capacité complémentaire, mais Playwright reste responsable du cycle de vie dans le code de test.
Trois propriétaires doivent rester distincts. Playwright gère l'objet et l'état du navigateur; l'application gère sa mémoire, sa déconnexion et son interprétation de session; le service gère les sessions serveur, la révocation et la conservation. context.close() libère le contexte, mais ne révoque pas un jeton accepté par le serveur et ne supprime aucune donnée distante.
Le cycle doit être visible dans le code. Créez le contexte dans le fixture le plus court, transmettez ses pages aux helpers et fermez-le dans finally. Un contexte global accumule pages, workers et caches et rend les tests dépendants de l'ordre. Une durée courte rend l'état initial et l'échec plus faciles à reproduire.
La création est un contrat
Les options font partie du contrat du test. Définissez seulement langue, fuseau, permissions, proxy, viewport et état nécessaires au scénario autorisé. Une option ne garantit pas que l'application l'acceptera. Notez la version du navigateur et n'insérez jamais de véritables identifiants dans les fixtures, traces ou captures.
Isolation et comptes autorisés
Deux contextes du même navigateur peuvent accéder au même origine sans partager cookies ni Web Storage. Cela permet de tester rôles et changement de compte. Utilisez des comptes synthétiques ou explicitement autorisés; ne déduisez pas l'existence d'un compte depuis un site cible. Un contexte propre est une entrée connue, pas une preuve d'identité.
L'isolation a des limites. Le serveur peut corréler ses requêtes et l'application peut appeler une autre origine. Le contexte n'isole ni boîte mail, ni fournisseur de paiement, ni base partagée, ni fichiers du runner. Pour une iframe externe, documentez séparément son propriétaire de session et de nettoyage. L'isolation du navigateur ne change pas la conservation côté service.
Les tests parallèles doivent avoir chacun leur propriétaire. Donnez un contexte, un compte synthétique et un répertoire de téléchargement à chaque worker. Ne partagez pas un fichier storageState modifiable. Copiez un état de base vers un chemin temporaire isolé avant la création du contexte pour éviter les écritures concurrentes.
Un changement de compte est une transition, pas un rechargement. Suivez la déconnexion prévue, nettoyez l'état du premier compte si l'application l'exige et créez un second contexte avec son propre état. Vérifiez la prochaine requête et le repli visible; un worker, une file hors ligne ou un autre onglet peut encore afficher l'ancien compte.
Isolation ne signifie pas suppression
Fermer un contexte termine son état géré par le navigateur, mais le service peut garder des journaux ou une session sur un autre appareil. Supprimer le fichier storageState ne supprime pas une session serveur. Affirmez seulement ce qui est observé: contexte fermé, nouvel état local absent et requête suivante non authentifiée si le contrat le prévoit.
storageState comme entrée et sortie
storageState est une instantanée sérialisée chargée lors de la création. Elle contient souvent cookies et stockage d'origine pour éviter une nouvelle connexion. Traitez-la comme un artefact sensible: permissions limitées, aucune publication, aucune validation Git et uniquement des comptes synthétiques approuvés.
Cette instantanée n'est pas une sauvegarde complète. Elle peut omettre la mémoire, les caches de workers, IndexedDB créée plus tard, les fournisseurs natifs et les sessions serveur. Un changement de schéma peut la rendre obsolète. Une lecture réussie par le navigateur ne prouve pas que le serveur acceptera les cookies ni que le parcours est prêt.
Écrivez chaque résultat dans un chemin nouveau par worker. Ne remplacez pas une base que d'autres lectures utilisent. Un fichier partiel doit être invalidé ou mis en quarantaine. Conservez autour du fichier la version du navigateur et le but du compte, jamais les secrets dans les journaux.
Rafraîchissez l'état consciemment. Si la session expire, relancez le setup autorisé ou échouez avec une cause claire. Ne réessayez pas avec un compte inconnu trouvé par hasard. Validez l'état avec une requête sans contenu sensible et arrêtez-vous avant de consulter des données inutiles au test.
Ce que prouve un état chargé
Vérifiez seulement le contrat requis: compte synthétique attendu, route protégée et page de départ connue. N'énumérez pas d'identifiants et n'imprimez pas de jetons. Si l'état manque, est bloqué ou expiré, utilisez le chemin de connexion approuvé et exposez clairement cette limite.
Pages, workers et fermeture déterministe
Un contexte peut contenir plusieurs pages, frames, workers et requêtes. Attendez les actions appartenant au test, capturez un statut minimal et utilisez try/finally. Une sortie globale du processus ne remplace pas le nettoyage explicite et masque les fuites de ressources.
Le nettoyage doit tolérer un second appel. Préservez la première erreur, ajoutez l'information de fermeture et ne transformez pas une erreur de teardown en succès. Les traces et captures doivent exclure secrets, jetons et données personnelles.
Un service worker peut servir un cache, conserver une file ou travailler après la fermeture d'une page. Pour un parcours de déconnexion, vérifiez le message ou l'invalidation documentés avant de fermer. Un nouveau contexte ne peut pas annuler une mutation déjà envoyée au serveur.
Fermez pages, téléchargements, descripteurs et enregistrements créés par le test. Supprimez uniquement les temporaires dont le test est propriétaire. Conservez un reçu minimal avec scénario, version, résultat et nettoyage selon la durée approuvée.
Échecs et nouvelles tentatives
Une nouvelle tentative est acceptable pour une panne réseau transitoire documentée. Elle doit créer un nouveau contexte avec les mêmes entrées synthétiques autorisées. Ne réutilisez pas une page inconnue ni l'état produit par l'essai précédent; séparez setup, assertion et infrastructure.
Observabilité sans collecte
Les preuves décrivent des transitions sans recueillir de données privées. BotBrowser fournit des contextes isolés pour des parcours autorisés, mais ne révoque pas les sessions serveur, ne nettoie pas l’application et ne gère pas les secrets.
Capacité et limites de BotBrowser
BotBrowser fournit des BrowserContexts isolés avec cookies, stockage et sessions séparés. Cela aide à comparer deux comptes de test connus et à vérifier qu'un nouveau contexte n'hérite pas de l'état local précédent. Playwright reste responsable de créer, utiliser et fermer les contextes.
BotBrowser ne remplace ni la gestion Playwright, ni le nettoyage de l'application, ni l'invalidation serveur, ni la protection des secrets. Il ne rend pas valide une cookie expirée, ne garantit pas la suppression d'un cache et n'autorise aucun compte. Le propriétaire doit fournir des entrées synthétiques autorisées.
Pour une revue contrôlée, notez version, objectif, source de l'état, compte synthétique et nettoyage attendu. Créez deux contextes, exécutez un parcours borné, fermez-les dans finally et comparez les résultats minimaux. Les actions serveur doivent être vérifiées par une API de test ou un contrat visible.
La répétabilité d'un profil n'est pas une garantie de persistance. Le navigateur, le schéma, la politique serveur ou le compte peuvent changer. Revalidez après une mise à jour et, si l'état manque, arrêtez-vous à la limite autorisée au lieu de chercher une autre identité.
Liste pratique du cycle
Avant chaque scénario, listez contexte, pages, workers, cookies, état, session serveur, file hors ligne et temporaires. Marquez chaque élément comme entrée, sortie ou donnée jetable. Cette carte attribue à chaque fixture une action de nettoyage précise.
Pendant le setup, créez un contexte neuf avec peu d'options, chargez un état synthétique et vérifiez le départ. N'enregistrez ni en-têtes, ni jetons, ni identifiants, ni corps complets. Lors d'un changement de compte, utilisez la déconnexion documentée ou un second contexte.
Pendant le teardown, attendez le travail du test, fermez pages et contexte dans finally et écrivez un résultat minimal. Empêchez les workers d'écraser un fichier. Mettez en quarantaine les sorties malformées et ne supprimez que les temporaires propres au test.
Après une mise à jour du navigateur ou de l'application, répétez isolation, chargement, expiration, déconnexion, changement de compte, activité du worker et fermeture après assertion. Une exécution réussie démontre le contrat testé, pas une suppression serveur universelle.
La règle est de créer petit, isoler, sérialiser uniquement un état synthétique autorisé, vérifier la frontière applicative et fermer toujours. Consultez aussi le modèle de stockage et le cycle du cache service worker.
Forme du fixture et propriété visible
Gardez création, actions, assertions et fermeture séparées afin que la propriété de chaque ressource reste claire.
Le test utilise un compte synthétique autorisé.
Le contexte reçoit seulement les options nécessaires.
Chaque worker écrit dans un fichier distinct.
La fermeture conserve l'erreur initiale.
Le serveur reste propriétaire de sa session.
Le nettoyage local n'efface pas un compte distant.
Les traces sont conservées selon une durée approuvée.
La vérification est répétée après une mise à jour.
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.