5 consejos para usar Playwright Test Agents

La release estable consultada es la v1.64.1, publicada el 14 de octubre de 2026. La guía a continuación trata sobre los agentes de la biblioteca principal, no de Playwright CLI, que ya explicamos en otro artículo.

En este artículo vas a ver:

• El rol de cada agente y cómo se conectan.
• Cinco prácticas para obtener pruebas revisables, no solo más archivos.
• Qué revisar antes de usar agentes en el flujo de integración continua.
• Una alerta actual sobre la imagen Docker de Playwright v1.64.1.

Playwright Test Agents organizan un ciclo, no un equipo autónomo

El Planner explora la interfaz y transforma una descripción del producto en un plan de pruebas. El Generator usa ese plan para crear pruebas Playwright. El Healer investiga fallas y propone cambios para recuperar pruebas rotas.

La documentación muestra a los agentes trabajando a partir de una especificación inicial llamada seed.spec.ts. El Planner puede descubrir la interfaz y producir casos; luego, el Generator convierte los casos en pruebas automatizadas.

El Healer entra cuando una prueba falla. Examina la ejecución, sugiere una corrección y puede repetir el ciclo, pero una prueba aprobada no prueba por sí sola que el producto esté correcto.

La biblioteca Playwright soporta Chromium, Firefox y WebKit por una API común, como describe el README oficial. Ese alcance ayuda a probar diferencias entre navegadores, pero no elimina la necesidad de revisar qué navegadores y versiones importan para tu público.

Este artículo trata sobre los Test Agents del repositorio microsoft/playwright. La Playwright CLI para interactuar con un navegador es otro proyecto y tiene otro uso: comandos de navegador accionados por el agente.

5 consejos para usar Playwright Test Agents con criterio

Consejo 1: entrega al Planner un flujo y un estado inicial claros

Comienza con un viaje corto, como entrar a una página, completar un formulario de prueba y confirmar el mensaje final. Indica los datos disponibles y el resultado esperado, sin mezclar varios objetivos.

Una semilla bien delimitada le da al Planner un punto de partida verificable. Si el agente no sabe qué estado inicial usar, el plan puede reflejar suposiciones sobre cuentas, permisos o datos que no existen en el entorno.

Consejo 2: revisa el plan antes de pedir código al Generator

Lee los pasos y verifica que cada caso corresponda a un requisito real. Elimina acciones repetidas, agrega estados de error importantes y corrige cualquier expectativa que no forme parte del producto.

La documentación oficial de los Test Agents muestra este prompt de planificación. La imagen es una captura de la solicitud al Planner, no un resultado de prueba ni una prueba de que todos los escenarios fueron cubiertos.

Consejo 3: usa el Generator para transformar criterios en verificaciones

Después de aprobar el plan, pide al Generator que cree pruebas alineadas a los pasos y a las reglas de aceptación. Prefiere verificaciones del comportamiento que percibe la persona, como mensaje de confirmación, estado guardado o bloqueo de un formulario inválido.

Evita aceptar una suite que solo repite detalles internos de la pantalla. Una prueba atada a nombres de clases o al orden de componentes puede fallar por un cambio visual sin que la experiencia se haya roto.

Consejo 4: trata al Healer como asistente de diagnóstico

Cuando una prueba falle, examina la causa antes de dejar que el Healer altere el código. Una falla puede revelar un defecto en el producto, un dato de prueba inestable o un cambio legítimo en la interfaz.

Revisa el diff propuesto, confirma que la aserción sigue midiendo el requisito y ejecuta la suite relevante. Si la corrección solo elimina la verificación que falló, la prueba puede quedar verde sin proteger el comportamiento que motivó su creación.

Consejo 5: regenera definiciones y registra las decisiones

Los agentes dependen de instrucciones y herramientas compatibles con la versión de Playwright usada en el proyecto. Cuando actualices la biblioteca, genera nuevamente las definiciones según la documentación y revisa el diff antes de reemplazar archivos existentes.

Mantén en el repositorio las pruebas aprobadas, no una salida cruda del agente como si fuera una especificación final. Registra qué requisitos cubre cada prueba y quién revisó los cambios sugeridos por el Healer.

Para llevar las pruebas a una rutina automatizada, el artículo sobre GitHub Agentic Workflows y automatización de repositorios explica otra capa de ejecución. Los agentes de prueba y el flujo de CI tienen responsabilidades diferentes.

La seguridad de Playwright exige separar la biblioteca de la imagen Docker

El repositorio usa licencia Apache-2.0, como muestra el archivo LICENSE, y la página de advisories consultada no lista aviso publicado. Esto no significa que toda imagen o configuración de navegador sea automáticamente segura.

Un issue de GitHub reporta 245 hallazgos de CVE en el scanner usado por el autor para la imagen Docker basada en Playwright v1.64.1, de los cuales 24 fueron clasificados como críticos por él. Es un relato en issue, no un advisory oficial ni una medida de exposición de cada entorno.

La propia issue #43664 registra que una actualización de la imagen llegó a fusionarse en main y fue revertida el 5 de noviembre de 2026. Como la última release estable consultada continúa en v1.64.1, no asumas que la revisión de Chromium más nueva esté en la imagen marcada solo con esa versión.

Si tu equipo usa la imagen Docker, revisa el historial de actualización y la versión de Chromium dentro del propio artefacto. La página de security advisories de Playwright y la issue que reporta la imagen v1.64.1 ayudan a separar avisos publicados de relatos aún en discusión.

Ejecuta pruebas en staging, con datos ficticios y permisos limitados. Los Test Agents automatizan etapas de planificación y ejecución, pero no aíslan por sí solos un navegador que recibe credenciales o acceso a datos reales.