QA The Other WayGarantía de calidad para la era de las pruebas escritas por IA. QA The Other Way.
Práctico QA

Reutilice el estado de inicio de sesión. No publiques el secreto.

Trate el estado guardado del navegador como una credencial y mantenga la cobertura de inicio de sesión separada de las pruebas que lo reutilizan.

7 min de lecturaQA The Other Way
Un diagrama de bloqueo creado que separa el estado reutilizable de la distribución pública.
Ilustración editorial de autor.
Vídeo ilustrativo de este artículo. Texto en pantalla en inglés; seleccione subtítulos para este idioma.

Edición traducida. Los identificadores técnicos permanecen en su forma original.

Trate el estado guardado del navegador como una credencial y mantenga la cobertura de inicio de sesión separada de las pruebas que lo reutilizan.
Demostración local ilustrativa. Sin cuenta real, datos de clientes ni interfaz de proveedor.

Una suite de lanzamiento inicia sesión antes de cada pequeña comprobación. La mayor parte del recorrido se pasa esperando el mismo formulario de inicio de sesión. Guardar el estado autenticado del navegador puede eliminar esa repetición, pero el archivo guardado no son datos de prueba inofensivos. Puede contener suficiente información para actuar como cuenta de prueba.

Esta guía sigue la documentación de autenticación de Playwright para hacer explícito el límite. La captura de pantalla adjunta es una pantalla de cuenta falsa local. No se utilizó ningún inicio de sesión, token o registro de cliente real. La pregunta es cómo preparar el estado reutilizable de forma segura, no cómo eludir la política de autenticación de una aplicación.

Decida qué puede reutilizar la suite

Una prueba de la configuración de un perfil normalmente necesita una sesión autenticada. No es necesario volver a utilizar el formulario de inicio de sesión. Una prueba de inicio de sesión en sí misma tiene un trabajo diferente: verificar el flujo de autenticación real, el comportamiento de rechazo y las reglas de sesión relevantes. El estado de reutilización en el primer grupo no debe borrar silenciosamente el segundo grupo.

Escriba esos grupos antes de agregar un acceso directo. Un proyecto de instalación puede realizar el inicio de sesión aprobado y guardar el estado; Las pruebas dependientes pueden comenzar desde ese estado. La guía de autenticación muestra este patrón. El estado debe pertenecer a una identidad de prueba controlada en un entorno aprobado, con solo los privilegios que necesita la prueba.

// After your approved test-account login has completed:
await expect(page.getByRole('button', { name: 'Sign out' })).toBeVisible();
await page.context().storageState({ path: 'playwright/.auth/user.json' });

El botón visible es el contrato de preparación de nuestra aplicación ilustrativa, no una prueba universal de que todos los métodos de autenticación han finalizado. Es posible que su aplicación necesite una condición estable diferente. Espere hasta que se establezca la sesión antes de guardarla, o la siguiente prueba puede recibir un estado incompleto y producir una falla confusa.

El archivo pertenece fuera del repositorio

Playwright advierte que el estado guardado del navegador puede incluir cookies confidenciales y encabezados que se pueden utilizar para suplantar una cuenta. Su documentación desaconseja enviar estos archivos a repositorios públicos o privados. Un repositorio privado sigue siendo un canal de distribución, no un almacén de credenciales seguro.

playwright/.auth/

Ignorar el directorio es prevención, no corrección. Si un archivo de estado ya se ha confirmado, eliminarlo del árbol de trabajo no borra las revisiones anteriores. Deje de distribuir ese artefacto y siga el proceso de exposición de credenciales de su organización. No incluya un archivo de estado real en un tutorial, archivo adjunto de problema, paquete de seguimiento o captura de pantalla para hacer una explicación más concreta.

Revise las reglas de carga de artefactos, así como las reglas de control de fuente. Un trabajo de CI puede cargar todo el espacio de trabajo después de fallar. Un archivo ignorado aún puede ingresar a ese archivo. Mantenga explícitamente el estado de inicio de sesión guardado fuera de los paquetes de depuración y las copias de seguridad que no lo necesitan. Utilice cuentas de prueba y acceso de corta duración cuando su entorno los admita.

La reutilización no es una promesa de por vida

El estado almacenado caduca. La guía recomienda eliminar el estado caducado y señala que los directorios de salida del proyecto se limpian antes de ejecutarse. Elija un ciclo de vida que coincida con la política de la sesión en lugar de asumir que el archivo de ayer es válido para siempre. Un error de configuración debería detener las comprobaciones dependientes con un motivo útil, no convertirse en docenas de errores de páginas no relacionadas.

Los mecanismos de almacenamiento también importan. La guía de autenticación de Playwright analiza las cookies, el almacenamiento local y otros mecanismos, con un manejo especial para el almacenamiento de sesiones. No asuma que cada implementación de inicio de sesión se captura mediante la llamada StorageState más simple. Verifique lo que utiliza su aplicación y verifique que un contexto nuevo pueda llegar a la página autenticada deseada.

Un experimento local seguro utiliza un estado falso para demostrar el mecanismo. Demuestra que el navegador puede restaurar ese valor seleccionado, no que se haya validado un proveedor de identidad, una política MFA o una sesión de producción. Mantenga esa distinción en el informe de prueba.

Dar pruebas paralelas con suficiente estado independiente.

Reutilizar una cuenta puede ser razonable para pruebas de solo lectura que no cambian el estado del servidor compartido. Se vuelve riesgoso cuando varias pruebas editan las mismas preferencias o registros. La separación del contexto del navegador no separa la cuenta del servidor. Nuestra guía de aislamiento anterior cubre esa colisión; aquí la regla práctica es hacer coincidir la configuración de autenticación con el patrón de mutación de la suite.

Mantenga la verificación de preparación, el alcance de la identidad, el mecanismo de almacenamiento, la regla de caducidad y las exclusiones de artefactos en una pequeña nota de configuración. Esa nota hace que una prueba generada sea más fácil de revisar. Un revisor puede ver por qué se reutiliza el inicio de sesión, qué pruebas de inicio de sesión aún se ejecutan y hacia dónde se le permite ir al estado.

AnyTest describe a los agentes que exploran una aplicación y crean pruebas de un extremo a otro para revisión humana. Aplique las mismas preguntas a cualquier viaje autenticado propuesto. Esta es una práctica de revisión, no una afirmación sobre el almacenamiento de credenciales o la configuración de inicio de sesión de AnyTest. Una configuración menos repetida es útil sólo cuando la suite aún protege el límite de autenticación.

Preguntas comunes

¿Puede un repositorio privado contener el archivo estatal?

La guía Playwright desaconseja enviar el estado guardado a repositorios públicos o privados. Trátelo como algo sensible.

¿El estado reutiliza el inicio de sesión de prueba?

No. Mantenga una cobertura de autenticación dedicada y nombre el acceso directo utilizado por los controles de dependientes.

Fuentes