Fixtures y aislamiento para automatización del navegador
Diseña fixtures de automatización con propiedad clara, estado aislado, workers paralelos seguros y limpieza 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.
La automatización fiable del navegador empieza con un fixture que posee un conjunto pequeño y declarado de recursos. Puede crear un contexto, una página, un directorio temporal y datos sintéticos de la aplicación. También debe indicar quién cierra cada recurso y qué resultado permanece cuando falla una aserción.
La regla central es que cada prueba recibe entradas conocidas, observa un resultado acotado y libera lo que creó. Playwright describe este modelo con sus fixtures de prueba, y Selenium explica las pruebas independientes en sus prácticas de prueba. Consulta también la guía de ciclo de vida de Playwright para separar el límite del fixture de la propiedad de una cuenta remota.
Escribe el contrato del fixture
El contrato debe nombrar entradas, salidas y propietario. Las entradas pueden incluir la versión del navegador, opciones del contexto, una cuenta sintética aprobada, un registro preparado y una carpeta propia del worker. Las salidas deben ser pequeñas: categoría del resultado, aserción visible y recibo de limpieza. Si la aplicación posee un registro remoto, el fixture no puede prometer borrarlo.
Mantén la preparación cerca del alcance que la necesita. Un contexto por prueba sirve cuando cada caso debe empezar limpio. Un navegador por worker puede reducir lanzamientos si cada worker crea su propio contexto y archivos. Una página global suele conservar cookies, service workers o memoria más tiempo del previsto. Haz visible el alcance en el nombre del fixture.
Separa la propiedad del navegador de la propiedad de la aplicación. El fixture puede abrir una página y usar un inicio de sesión autorizado, pero la aplicación define cómo termina la sesión y el servicio define cuánto conserva un registro. Cerrar un contexto libera estado del navegador; no revoca otra sesión ni deshace una mutación remota.
Registra etiqueta de escenario, versión, alcance, etiqueta de entrada sintética y resultado de limpieza. No guardes cookies, tokens, cuerpos completos ni texto personal en los registros habituales. El mantenedor debe decidir si la prueba cumplió su contrato sin abrir una copia de toda la sesión.
Elige un alcance que evite compartir estado
Proceso, navegador, contexto, página, worker y prueba son alcances distintos. Un navegador puede alojar varios contextos; un contexto agrupa páginas y almacenamiento; una página representa una pestaña. Pasa explícitamente el contexto o la página a los helpers en lugar de buscar una página global.
Usa un contexto nuevo cuando importen cookies, almacenamiento, permisos, service workers o un origen limpio. El aislamiento evita mezclar estado gestionado por el navegador, pero no es un aislamiento del sistema operativo. La aplicación aún puede escribir en servicios compartidos, y el runner puede compartir variables o archivos. Cada recurso externo necesita propietario y política.
Un snapshot storageState es una entrada con ciclo de vida, no una copia universal. Puede contener cookies y almacenamiento de origen, pero no memoria, colas de workers, credenciales nativas ni siempre la sesión del servicio. Trátalo como artefacto sensible y sintético. Copia una base de solo lectura a una ruta propia y marca inválido cualquier archivo parcial.
La misma regla aplica a perfiles de Selenium. Directorio de perfil, driver y binario forman una entrada de compatibilidad. Da a cada sesión una ruta propia y cierra el driver mediante su ciclo normal. La guía de integración de perfiles de Selenium amplía esta propiedad. Un perfil reproduce entradas declaradas, no la decisión de un servicio.
Prepara estado seguro para workers paralelos
Los workers paralelos fallan cuando comparten un archivo de estado, una carpeta de descargas, una cuenta sintética o un nombre de captura. Un archivo puede ser válido y pertenecer al worker equivocado. Asigna a cada worker una etiqueta de escenario y un directorio privado bajo la raíz de artefactos aprobada.
Carga una base de solo lectura y escribe el nuevo estado junto a ella. Un fixture de inicio de sesión puede renovar una sesión sintética y guardarla con worker e intento. Un resultado incompleto debe quedar aislado o marcado inválido. Nunca sustituyas una base que otro contexto pueda estar leyendo.
El navegador limpio no evita una carrera en el servicio. Prefiere registros sintéticos independientes, una operación de reinicio documentada o un caso de solo lectura. Si una mutación debe ser compartida, serializa esa operación y documenta su propietario. No arregles una carrera con una espera arbitraria.
Las observaciones de cada worker deben ser acotadas. Guarda categoría de URL, estado visible y nombre breve del error. Si un trace o una captura está autorizada, usa una ruta propia del worker y la retención normal. Un archivo con el nombre correcto pero contenido de otro worker es un resultado fallido.
Haz que la limpieza sea determinista
La limpieza forma parte de la corrección. Colócala en finally después de un éxito, una aserción, un timeout o un error de preparación. Cierra las páginas de vida corta y después el contexto que las posee. El dueño de un navegador compartido lo cierra cuando todos los contextos terminan; el contrato de despliegue decide si otro código solo debe desconectarse.
Conserva el primer error si la limpieza falla. Guarda el error de la prueba, intenta limpiar y añade el error de cierre como evidencia. Ocultar la aserción original dificulta el diagnóstico. Ignorar el cierre produce un resultado aparentemente verde con una sesión abierta.
Cierra descargas, grabaciones, descriptores y carpetas temporales creados por la prueba según sus APIs. Cerrar el contexto no borra un archivo copiado a un almacén de artefactos ni cancela una mutación enviada al servidor. Ejecuta el cierre de sesión de la aplicación mientras la página está disponible cuando el contrato lo exige.
La limpieza debe tolerar una segunda llamada. Un timeout puede dejar una página incompleta y un runner puede ejecutar un hook de seguridad después del fixture. Comprueba si el handle sigue siendo utilizable y ciérralo si conserva la propiedad. No cierres otro contexto solo porque su nombre parece similar.
Coordina reintentos y evidencias
Un reintento es una nueva ejecución, no la continuación de una página desconocida. Decide si la acción era de lectura y si la aplicación ofrece idempotencia o consulta de estado. Si se permite, cierra el contexto viejo, crea uno nuevo con las mismas entradas sintéticas y registra el intento. Un pase posterior no demuestra que el primer intento fuera inocuo.
Clasifica fallos de preparación, aplicación, aserción e infraestructura. Un archivo ausente es un problema del fixture; una respuesta rechazada puede pertenecer a la aplicación; una desconexión del driver es infraestructura. Un timeout identifica la señal visible que faltó, pero no explica por qué el servicio respondió así.
El diagnóstico debe nombrar la condición y no volcar la sesión. Incluye escenario, versiones, categoría de URL, hito esperado y estado de limpieza. Una captura de una página sintética puede ayudar, pero puede contener secretos. Limita acceso y caducidad; borrar después no recupera una copia ya compartida.
Ensaya el camino de fallo con una página sintética que omita una señal de preparación. El resultado esperado es un fallo acotado con esa señal y un recibo de limpieza. No hace falta consultar orígenes no relacionados ni ampliar la recolección para lograr un pase.
Revisa el límite de la aplicación
El aislamiento del navegador ofrece un punto de inicio conocido. No garantiza que dos sesiones de servidor sean independientes, que un servicio acepte una cookie ni que se ejecute la limpieza de la aplicación. Comprueba el límite que la prueba puede observar: estado local ausente, ruta protegida y siguiente solicitud documentada.
Prueba el cambio de cuenta como una transición. Usa el cierre de sesión soportado, elimina solo el estado que la aplicación documenta y crea el siguiente contexto con su propio estado aprobado. Comprueba un encabezado visible o un resultado de acceso. Otra pestaña, worker, cola offline o service worker puede conservar la vista anterior.
Mantén el fixture lejos del descubrimiento de cuentas y de la recolección de señales privadas. Una prueba autorizada necesita cuenta conocida, ruta declarada y resultado observable. Si una dependencia no está disponible, registra esa categoría y detente en el límite aprobado.
Después de actualizar navegador o aplicación, repite los casos que importan: contexto limpio, carga y expiración de estado, cambio de cuenta, salida de workers, archivos paralelos y cierre tras error. Compara el resultado visible y conserva las versiones probadas.
Capacidad y límite de BotBrowser
BotBrowser proporciona BrowserContexts aislados con cookies, almacenamiento y estado de sesión separados. Esto permite a un fixture autorizado repetir un flujo sintético y comprobar que un contexto nuevo no hereda estado local. La documentación de aislamiento multi cuenta de BotBrowser describe ese límite del navegador. BotBrowser no reemplaza la gestión del ciclo de vida de Playwright o Selenium, la limpieza de la aplicación, la invalidación de sesiones del servidor ni el manejo de secretos. No garantiza que una cookie caducada sea aceptada, no elimina una cola de trabajador del servicio y no borra registros de un proveedor. El propietario del fixture conserva esas responsabilidades.
Usa la capacidad como una entrada declarada, no como un resultado remoto. Registra versión, propósito del contexto, origen del estado, etiqueta del worker, limpieza esperada y resultado observado. Mantén la limitación junto al registro para no confundir un contexto local limpio con una eliminación remota.
Una revisión práctica pregunta si cada prueba posee su estado mutable, si un worker puede sobrescribir archivos, si todo fallo llega a la misma limpieza y si el resultado indica lo que no se observó. Estas respuestas hacen mantenible el fixture al cambiar el navegador o el framework.
Cuando una prueba usa una respuesta preparada, conserva la propiedad de sus entradas y salidas. El simulador pertenece al escenario, usa datos sintéticos y reinicia su estado con el contexto. Una respuesta preparada no demuestra que el servicio real conserve los mismos datos.
El directorio de artefactos también tiene un propietario. El worker escribe su resultado, pero CI decide quién puede leerlo y cuándo caduca. Separa el recibo corto de la captura o trace más sensible para que una revisión no abra contenido innecesario.
Una corrección de fixture debe cambiar la causa, no solo el síntoma. Si dos casos comparten un registro por error, sepáralos o define la operación compartida. Si la limpieza falla, conserva ese fallo y permite que el propietario del runner lo repare.
La documentación del escenario debe coincidir con el código ejecutado. Revisa el alcance cuando cambien navegador, framework, esquema de estado o servicio. Un contrato pequeño y actualizado evita reutilizar una ruta temporal como recurso común.
Antes de integrar un cambio, ejecuta un caso con contexto limpio, otro con estado caducado y otro que fuerce un fallo de limpieza usando el mismo recibo. Compara la etiqueta del worker, el alcance del recurso, la aserción visible y el estado final.
Mantén las entradas sintéticas y comparte solo el recibo corto. Si el comportamiento del servidor no coincide, entrega el identificador de solicitud al propietario de la aplicación; cerrar el contexto no prueba una eliminación remota.
Como capacidad de BotBrowser, puedes fijar una configuración de navegador coherente para cada contexto de prueba; BotBrowser no limpia por ti los datos que la aplicación conserva en sus propios servicios.
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.