Ciclo de vida y almacenamiento de BrowserContext en Playwright
Cómo crear contextos aislados, reutilizar estados autorizados y cerrar cada prueba de forma determinista.
Quieres la documentación estructurada de Primeros pasos?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
El ciclo en una vista
Playwright usa BrowserContext como un entorno de navegación aislado. Cada contexto tiene sus propias cookies, almacenamiento web, permisos y estado de service worker. El patrón fiable es crear el contexto con entradas conocidas, ejecutar un flujo autorizado, guardar un resultado mínimo y cerrarlo en el mismo ámbito. Esto evita que una prueba herede silenciosamente el estado de otra.
La guía de BrowserContext de Playwright explica los contextos independientes. La guía de autenticación documenta cómo guardar y cargar un estado autenticado. La documentación de aislamiento multi-cuenta de BotBrowser describe una capacidad del producto que complementa las llamadas de ciclo de vida de Playwright, pero no las sustituye.
Hay tres propietarios distintos. Playwright administra el objeto de contexto y el estado gestionado por el navegador. La aplicación administra memoria, limpieza y significado de sesión. El servicio administra sesiones, revocación, registros y retención. context.close() libera recursos del contexto, pero no revoca una sesión del servidor ni borra una fila de base de datos.
El ciclo debe aparecer en el código de la prueba. Crea el contexto dentro del fixture más pequeño, pasa sus páginas a las funciones auxiliares y ciérralo en finally. Un contexto global acumula páginas, workers y cachés y vuelve las pruebas dependientes del orden. Un ámbito corto deja claro cuál era el estado inicial cuando falla una prueba.
La creación es un contrato
Las opciones de creación forman parte del contrato. Define solo el locale, zona horaria, permisos, proxy, viewport y estado necesarios para el escenario autorizado. Una opción no garantiza que la aplicación acepte el valor. Registra el navegador y el perfil previstos, y nunca incluyas credenciales reales en fixtures, trazas o capturas.
Aislamiento y cuentas autorizadas
Dos contextos del mismo navegador pueden visitar el mismo origen sin compartir cookies ni Web Storage. Esto permite probar cambio de cuenta, roles y compras independientes. Usa cuentas sintéticas o autorizadas explícitamente; no descubras cuentas en el sitio objetivo. Un contexto limpio es una entrada conocida, no una señal sobre la identidad de quien navega.
El aislamiento tiene límites. El servidor puede correlacionar solicitudes y la aplicación puede enviar datos a otro origen. Un contexto no aísla buzones, proveedores de pago, bases de datos compartidas ni archivos del ejecutor. Si hay un iframe externo, documenta por separado quién posee su sesión y limpieza. El aislamiento del navegador no cambia la retención del servicio.
Las pruebas paralelas necesitan propietarios únicos. Asigna un contexto y una cuenta sintética por worker, usa directorios de descarga separados y no compartas un archivo storageState mutable. Si una prueba escribe mientras otra lee, aparece una condición de carrera. Copia un estado base a una ruta temporal aislada antes de crear el contexto.
Cambiar de cuenta es una transición, no una recarga. Ejecuta el cierre de sesión soportado, limpia el estado de cuenta si la aplicación lo exige y usa un segundo contexto con su propio estado autorizado. Comprueba la siguiente solicitud y la alternativa visible. Un worker, una cola offline o una segunda pestaña puede conservar la vista de la cuenta anterior.
Aislamiento no significa borrado
Cerrar un contexto termina su vida gestionada por el navegador, pero el servicio puede conservar auditorías o sesiones en otros dispositivos. Borrar un archivo storageState tampoco borra la sesión del servidor. Afirma solo lo comprobado: contexto cerrado, nuevo contexto sin estado local esperado y solicitud siguiente sin autenticación cuando ese es el contrato.
storageState como entrada y salida
storageState es una instantánea serializada que puede cargar un contexto. Suele contener cookies y almacenamiento de origen para iniciar una prueba autorizada sin repetir el login. Trátala como un artefacto con credenciales: limita permisos, no la publiques ni la confirmes en Git, y usa únicamente cuentas sintéticas aprobadas.
La instantánea no es una copia completa de la aplicación. Puede no incluir memoria, cachés de workers, IndexedDB creado después, proveedores nativos o sesiones del servidor. También puede quedar obsoleta cuando cambia el esquema. Que el navegador pueda leer el archivo no demuestra que el servidor acepte sus cookies ni que el flujo tenga todos sus requisitos.
Guarda el estado de salida en una ruta nueva por worker. No sobrescribas la base mientras otros workers la leen. Si el setup renueva cookies, crea un artefacto nuevo y conserva solo los metadatos mínimos. Un archivo parcial debe quedar invalidado o en cuarentena, nunca convertirse en la base de la siguiente ejecución.
Renueva el estado de forma deliberada. Si la sesión expira, repite el setup autorizado o falla con una causa clara. No pruebes otra cuenta automáticamente ni uses la cuenta que aparezca por accidente. Valida el estado con una petición inocua y detente antes de leer contenido que la prueba no necesita.
Qué demuestra un estado cargado
Después de cargarlo, verifica solo el contrato necesario: cuenta sintética esperada, ruta protegida y página inicial conocida. No enumeres identificadores ni imprimas tokens. Si el estado falta, está bloqueado o caducó, usa el login aprobado o muestra el límite de autenticación sin inventar una identidad.
Páginas, workers y cierre determinista
Un contexto puede tener varias páginas, frames, workers y solicitudes en segundo plano. Al cerrarlo, espera las acciones propiedad de la prueba y captura un resultado mínimo. Usa try/finally para que una aserción fallida no salte el cierre. Depender de que termine el proceso oculta fugas y dificulta reproducirlas.
El cierre debe tolerar una segunda llamada. Un helper puede ejecutarse después de un setup fallido y durante teardown. Conserva el primer error, añade el dato de cierre y no conviertas una excepción de limpieza en éxito. Trazas y capturas no deben contener secretos ni datos personales.
Un service worker puede servir caché, mantener una cola o trabajar tras cerrar una página. Si el flujo prueba logout o cambio de cuenta, comprueba primero el mensaje o invalidación documentados. Un nuevo contexto ofrece un inicio limpio del navegador, pero no deshace una mutación que el worker ya envió al servidor.
Libera páginas, descargas, descriptores y grabaciones creados por la prueba. Elimina solo temporales propios; no borres un perfil compartido para hacer pasar una prueba. Conserva un recibo pequeño con escenario, versión, resultado y cierre, según la política de retención.
Fallos y reintentos
Un reintento solo es razonable para una condición de red transitoria documentada. Debe crear un contexto nuevo con las mismas entradas sintéticas autorizadas. No reutilices una página desconocida ni el estado generado por un intento fallido. Separa fallos de setup, aserción e infraestructura para no ocultar un defecto real.
Observabilidad sin recopilación
La evidencia describe transiciones y no recopila datos privados. BotBrowser permite contextos aislados con cookies, almacenamiento y sesiones separadas para flujos autorizados, pero no revoca sesiones del servidor, no limpia la aplicación ni gestiona secretos.
Capacidad y límites de BotBrowser
BotBrowser proporciona BrowserContexts separados para comparar estados autorizados y ejecutar pruebas repetibles, pero no sustituye la limpieza de la aplicación, no revoca sesiones del servidor ni gestiona secretos.
BotBrowser ofrece BrowserContexts aislados con cookies, almacenamiento y sesión separados. Esto permite comparar dos cuentas de prueba conocidas, repetir un setup de estado y comprobar que un contexto nuevo no hereda el estado local del anterior. Playwright sigue siendo responsable de crear, usar y cerrar los contextos.
BotBrowser no sustituye la gestión del ciclo de vida, la limpieza de la aplicación, la invalidación de sesiones del servidor ni el manejo de secretos. No puede hacer válida una cookie caducada, asegurar que un worker haya borrado su caché, borrar la base de un proveedor ni autorizar una cuenta. El propietario de la prueba debe proporcionar entradas sintéticas autorizadas.
En una revisión controlada registra versión, propósito, origen del estado, cuenta sintética y resultado esperado. Crea dos contextos, ejecuta un flujo acotado, ciérralos en finally y verifica que el siguiente contexto empiece en el estado documentado. Compara resultados, no cuerpos privados. Las acciones de servidor deben verificarse por su API de prueba o contrato visible.
La repetibilidad de un perfil no garantiza persistencia. El navegador, el esquema, la política del servidor o la cuenta pueden cambiar. Revalida tras versiones soportadas y rota credenciales sintéticas. Si falta o se rechaza el archivo, detente en el límite autorizado en lugar de buscar otra cuenta.
La creación usa solo opciones mínimas y datos sintéticos autorizados. Cada worker paralelo escribe en una ruta de estado propia.
El cierre en finally conserva el error original.
Una respuesta del servidor sigue siendo propiedad del servicio.
La limpieza local no equivale a borrar una cuenta.
Los traces requieren acceso restringido y caducidad.
Una nueva versión exige repetir los casos de ciclo de vida.
El resultado debe ser legible sin contenido privado.
Lista práctica de ciclo de vida
Antes de cada escenario, anota contexto, páginas, workers, cookies, estado, sesión del servidor, cola offline y temporales. Marca cada elemento como entrada, salida o dato descartable. Así, context.close() no se confunde con borrado de aplicación y cada fixture tiene un dueño claro.
Durante setup crea un contexto nuevo con pocas opciones, carga solo estado sintético y comprueba el inicio esperado. No registres cabeceras, tokens, identificadores ni cuerpos completos. Al cambiar de cuenta usa el flujo documentado o un segundo contexto y comprueba la siguiente petición. Si el estado caducó, falla de forma cerrada o usa el login aprobado.
Durante teardown espera el trabajo propio, cierra páginas y contexto en finally, y escribe un resultado mínimo. Evita que workers sobrescriban archivos. Pon en cuarentena salidas malformadas y elimina solo temporales propios. Una segunda limpieza no debe ocultar el primer error.
Tras una versión del navegador o de la aplicación repite aislamiento, carga, expiración, logout, cambio de cuenta, worker activo y cierre tras una aserción fallida. Consulta la documentación actual antes de afirmar compatibilidad. Una ejecución correcta demuestra el contrato probado, no persistencia universal ni borrado del servidor.
La regla central es crear de forma acotada, aislar deliberadamente, serializar solo estado sintético autorizado, validar el límite de aplicación y cerrar siempre. BrowserContext es una buena unidad de pruebas cuando se mantiene separada la responsabilidad del navegador, la aplicación y el servidor. Consulta también el modelo de almacenamiento del navegador y la caché de service worker.
Forma del fixture y propiedad visible
Mantén creación, acciones, aserciones y cierre en partes separadas para que la propiedad de cada recurso sea clara.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.