Playwright con IA: agentes, MCP y tests que se reparan solos (qué sirve y qué no)

Respuesta corta: Playwright incluye desde la versión 1.56 tres agentes de IA (planner, generator y healer) y un servidor MCP que permite a un asistente de IA manejar un navegador real. Sirven para acelerar el primer borrador de un test y el mantenimiento rutinario, pero no reemplazan la revisión humana: un agente que "repara" un test puede estar tapando un bug real.

Qué trae Playwright hoy

Hay tres piezas distintas, y conviene no mezclarlas:

1. Playwright MCP: un servidor que expone el navegador a un asistente de IA (por ejemplo, un asistente de código) usando el árbol de accesibilidad de la página en lugar de capturas de pantalla. Así el modelo "ve" roles, nombres y estados, no píxeles.
2. Test agents: tres agentes que se pueden usar por separado o encadenados.
   • Planner: explora la aplicación y produce un plan de pruebas en Markdown.
   • Generator: convierte ese plan en archivos de Playwright Test.
   • Healer: ejecuta las pruebas y trata de reparar las que fallan.
3. ARIA snapshots: una forma de afirmar la estructura de accesibilidad de la página en lugar de selectores CSS frágiles.

Para empezar, según la documentación oficial:

npx playwright init-agents --loop=vscode

También existen las opciones --loop=claude, --loop=codex y --loop=opencode. El comando genera las definiciones de los agentes, una carpeta specs/ con los planes legibles y una carpeta tests/ con las pruebas generadas, además de un seed.spec.ts que fija el contexto inicial.

Un ejemplo de prueba estable con ARIA

await page.goto("https://playwright.dev/");
await expect(page).toMatchAriaSnapshot(`
  - banner:
    - heading /Playwright enables reliable end-to-end/ [level=1]
    - link "Get started":
      - /url: /docs/intro
`);

Este tipo de aserción sobrevive a cambios de clases o de estructura visual, porque verifica lo que el usuario (y un lector de pantalla) realmente percibe.

Dónde ahorra tiempo de verdad

• Primer borrador de cobertura: el planner recorre la app y propone escenarios que a un equipo apurado se le escapan.
• Tests de humo y flujos básicos: login, alta de un registro, búsqueda. Son repetitivos y el modelo los resuelve bien.
• Mantenimiento rutinario: un selector que cambió de nombre es el caso ideal para el healer.

Dónde hay que tener cuidado

• El healer puede ocultar bugs. Si un botón desaparece por un error real, un agente "arreglará" el test cambiando el selector o saltándolo. La documentación misma advierte que puede omitir pruebas cuando detecta funcionalidad rota. Todo cambio del healer debe pasar por revisión de código, como cualquier otro.
• Necesitas un buen test semilla y, idealmente, un documento de requisitos del producto. Sin contexto, el plan será genérico.
• Las definiciones de agentes deben regenerarse cuando actualizas Playwright; si no, quedan desfasadas.
• Un test generado que pasa no demuestra que valide lo correcto. Revisa qué afirma, no solo que esté en verde.

Cómo incorporarlo sin riesgos

1. Empieza en un módulo acotado (por ejemplo, el login o el checkout).
2. Pide un plan, edítalo tú y recién entonces genera el código.
3. Revisa cada test generado como si lo hubiera escrito un desarrollador junior: nombres, aserciones y datos de prueba.
4. Deja el healer como sugerencia en un Pull Request, nunca como cambio automático a la rama principal.
5. Mide: ¿cuántas horas de mantenimiento ahorró y cuántos falsos verdes aparecieron?

La IA acelera la parte mecánica; el criterio sobre qué probar y cuándo un resultado es confiable sigue siendo del equipo de QA. Si quieres ver el punto de partida, mira cómo automatizar tu primer test con Playwright, o revisa qué automatizar primero.

¿Quieres evaluar cómo aplicar esto en tu equipo sin romper tu suite actual? Conversemos.

Fuentes: documentación oficial de Playwright Test Agents y de ARIA snapshots.