Otro navegador no significa otra cuenta

Dos tests de ejemplo se ejecutan a la vez. El primero espera la zona horaria UTC. El segundo guarda "Europe/Riga". Cada uno tiene un contexto de navegador nuevo, pero ambos usan la misma cuenta. El primero falla porque el registro del servidor cambió, aunque las cookies estén separadas.

Esta distinción es importante cuando un agente genera más cobertura que la que tenía su anterior suite. La ejecución paralela puede exponer suposiciones de estado compartido que estaban ocultas cuando las pruebas se ejecutaron una tras otra. El artefacto práctico es un mapa de propiedad: qué prueba puede escribir qué cuenta y registro, y cuándo se restablece ese estado.

Dibuja los dos límites por separado

La guía de autenticación de Playwright explica el aislamiento del contexto del navegador y la carga del estado autenticado. También advierte que las pruebas que modifican el estado del lado del servidor deben utilizar cuentas diferentes cuando el uso simultáneo pueda afectar a otra prueba. Un contexto es un límite de cliente. Un espacio de nombres de cuenta, inquilino o registro es un límite de aplicación. Ninguno sustituye al otro.

Enumere ambos en revisión. Una prueba generada debe identificar el contexto que utiliza y los datos que puede modificar. Si solo lee contenido inmutable, compartir una cuenta puede ser razonable. Si cambia la configuración, crea pedidos o edita un documento compartido, revise la cuenta y registre la propiedad antes de aumentar los trabajadores paralelos.

Elija la unidad de propiedad útil más pequeña

La guía Playwright documenta una cuenta por trabajador paralelo para pruebas que modifican el estado del lado del servidor. Eso puede reducir la interferencia entre los trabajadores. Esto no significa que cada prueba interna de un trabajador pueda dejar cambios arbitrarios. Restablezca o inicialice el estado que necesita cada prueba y haga explícita la limpieza.

A veces, la unidad más segura es un registro único por prueba en lugar de una cuenta por prueba. Para una lista de tareas propiedad del equipo, cuentas separadas aún pueden escribir la misma lista compartida. Para un flujo de pago, puede ser necesario un carrito único o un espacio de nombres de pedido. Elija la unidad de las reglas de uso compartido reales del producto, no del nombre de la API del navegador.

Un contrato de datos que un agente puede seguir

Escriba cuatro campos al lado de cada escenario: espacio de nombres del propietario, estado de configuración, escrituras permitidas y comportamiento de limpieza. Un contrato ilustrativo podría reservar un usuario de prueba para un trabajador, sembrar un carrito vacío antes de la prueba, permitir crear solo pedidos sintéticos y eliminar esos pedidos después de conservar la evidencia de falla. Indique qué sucede cuando falla la limpieza; de lo contrario, la siguiente ejecución hereda un misterio.

Mantenga la configuración independiente del éxito de otra prueba. Los accesorios de Playwright proporcionan un ciclo de vida estructurado para preparar y publicar recursos de prueba. Utilice ese ciclo de vida para hacer legible la propiedad, no para ocultar una cuenta compartida global detrás de un nombre de dispositivo conveniente. El revisor debería poder encontrar quién posee cada recurso mutable.

Un equipo de control de calidad puede utilizar este mapa para dedicar menos tiempo a buscar fallos accidentales en las pruebas cruzadas. Un equipo sin control de calidad puede comenzar con un flujo crítico y un grupo de cuentas provisionales limitado. Ninguno de los dos necesita construir un entorno enorme antes de medir si el primer flujo es útil.

El estado de autenticación es un archivo secreto

Playwright advierte que el estado guardado del navegador puede contener cookies y encabezados que pueden hacerse pasar por una cuenta. Su guía desaconseja enviar esos archivos a repositorios, incluidos los privados. Trátelos como credenciales: manténgalos fuera de los archivos fuente, restrinja el acceso y regrénelos cuando sea apropiado.

Nunca le dé a un agente exploratorio una sesión de producción solo porque la configuración de inicio de sesión le resulte inconveniente. Utilice cuentas provisionales con los permisos necesarios para el escenario. Un navegador independiente que lleve una cookie de administrador sigue siendo un administrador.

Cuente los fallos falsos como trabajo real

Realice un seguimiento de los errores causados por el estado compartido por separado de las regresiones del producto. Incluya los minutos dedicados a restablecer cuentas e investigar interferencias en el costo de reparación de un piloto de automatización. Una mayor cantidad de pruebas generadas pueden aumentar la cobertura, pero también pueden aumentar la contención si la propiedad no está clara. El ahorro se produce cuando la cobertura útil y los datos predecibles reducen la repetición del trabajo, no cuando el recuento de pruebas por sí solo aumenta.