Lección 8 de 8 · 13 min
Los agentes de Playwright: planner, generator y healer
Al terminar sabrás
13 min- Explicar qué hace cada agente de Playwright y cómo se instalan
- Revisar el plan, los tests generados y las reparaciones del healer
- Conocer lo nuevo de Playwright 1.62 y 1.63 que cambia tu flujo
Construyes: El flujo de revisión de tu equipo para lo que generan y reparan los agentes de Playwright.
La IA ya vive dentro del framework
Hasta 2025, usar IA con Playwright era conectar algo por fuera: un chat al que le pegabas código, o un servidor MCP que había que instalar aparte. Desde la versión 1.56, Playwright trae agentes propios, y desde la 1.62 su servidor MCP y su CLI vienen en el mismo paquete.
Este resumen corresponde al estado de Playwright al 28 de septiembre de 2026 (versión 1.63), según su documentación oficial.
Los tres agentes
| Agente | Qué hace | Qué revisa QA |
|---|---|---|
| planner | Explora la app y escribe un plan de pruebas en Markdown | Que el plan cubra los riesgos que importan, no solo el camino feliz |
| generator | Convierte ese plan en tests de Playwright Test | Que cada test proteja algo: los 7 chequeos |
| healer | Corre la suite y repara los tests que fallan | Cada reparación: por qué falló el test y si el arreglo tapa un bug |
Se instalan con un comando que indica con qué cliente vas a trabajar:
npx playwright init-agents --loop=claude
Los clientes soportados en --loop son vscode, claude, codex y opencode (en VS Code, desde la versión 1.105). Las definiciones de los agentes se regeneran en cada actualización de Playwright, así que conviene no editarlas a mano.
El límite que importa: el lenguaje
Playwright soporta TypeScript, JavaScript, Python, .NET y Java. Sus agentes, no: hoy son solo para el runner de JavaScript y TypeScript. Python y Java tienen solicitudes abiertas, sin implementación.
Para un equipo que escribe su suite en Python, eso significa elegir: mantener una parte en TypeScript para usar los agentes, esperar el soporte o usar el MCP con otro agente de código.
El healer es el que más revisión necesita
Un test que falla puede fallar por dos razones: cambió la UI (el test está mal) o cambió el comportamiento (la app está mal). El healer está diseñado para el primer caso. Si se le deja actuar sin revisión en el segundo, convierte un bug real en una suite verde.
Ejemplo: el botón "Pagar" desapareció del checkout por un error. El healer busca un elemento parecido, apunta el test a "Volver al carrito", y la suite pasa. Nadie se entera hasta que los clientes no pueden pagar.
La regla para el equipo: ninguna reparación entra sin que una persona lea el diff y confirme que el test falló porque la UI cambió a propósito.
Lo nuevo de 1.62 y 1.63
- MCP y CLI incluidos (1.62).
npx playwright mcpynpx playwright clivienen con Playwright: ya no se instalan aparte. Para conectar Claude Code:claude mcp add playwright -- npx playwright mcp. - Agent CLI. Una CLI pensada para agentes de código: comandos económicos en tokens, skills instalables, un navegador persistente y snapshots de accesibilidad con referencias.
- Test locks (1.63). Los tests que comparten un recurso (una cuenta, un registro de la base) declaran un candado con nombre, para no pisarse cuando corren en paralelo.
locator.visible()(1.63). Reemplazo recomendado del pseudo-selector:visible.
Cierre del curso
Locators, fixtures, traces, paralelismo, visual, API, red, tiempo, IA y agentes: es el stack Playwright con el que trabajan hoy los equipos que lo usan en serio. Lo que no cambió en ninguna versión es la disciplina: ningún test entra sin haberlo visto fallar, lo haya escrito una persona, un agente o el healer.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Qué hace el agente healer de Playwright?
2. Tu equipo escribe sus tests de Playwright en Python. ¿Puede usar los agentes hoy?
3. ¿Qué cambió en Playwright 1.62 con el servidor MCP?
Reto: el flujo de revisión de tu equipo
Si tu suite es JS/TS, instala los agentes en un proyecto de prueba, pídele al planner un plan para un flujo pequeño y al generator los tests.
Escribe en una página cómo revisa tu equipo cada una de las tres salidas: el plan, los tests generados y las reparaciones del healer.