¿Qué fue exactamente lo que quedó en verde? Una prueba de Playwright puede hacer clic en el botón correcto, encontrar un toast de éxito y aun así dejar un pedido sin persistir. El código pasa. La regla de negocio no.

Ese es el riesgo más engañoso de las pruebas generadas por IA: parecen completas porque reproducen la secuencia visible. La validación empieza cuando cambias la pregunta "¿se ejecutó la prueba?" por "¿qué estado demostró?".

Diagrama que muestra una prueba de Playwright generada por IA pasando por el navegador, la verificación del resultado y la revisión de evidencia.

Resumen práctico

  • Trata una prueba generada como un borrador, no como una prueba automática.
  • Escribe la consecuencia de negocio antes de aceptar locators y clics.
  • Ejecuta el navegador y comprueba el estado observable más allá de los mensajes temporales.
  • Conserva el trace, el informe y el diff de reparación antes de poner la prueba en CI.

El verde puede engañar

Una prueba end-to-end resulta útil cuando conecta una acción del usuario con una consecuencia que importa al producto. La documentación de Playwright recomienda probar el comportamiento visible y usar aserciones web-first, pero un agente todavía puede elegir la señal más barata para producir un resultado verde. El runner debe revisar esa elección.

El falso positivo aparece cuando la aserción confirma un detalle intermedio. Un toast puede decir que la petición empezó. Una redirección puede ocurrir antes de que el backend guarde los datos. Un locator puede encontrar un elemento oculto. En todos esos casos, la secuencia parece correcta sin cerrar el contrato del flujo.

Compara estas dos pruebas:

test("completa el checkout", async ({ page }) => {
  await page.getByRole("button", { name: "Pagar" }).click();
  await expect(page.getByRole("status")).toHaveText("Pedido creado");
});

La primera solo comprueba un mensaje. Una versión más fuerte comprueba la página de confirmación y, cuando el producto lo permite, lee el estado mediante una API exclusiva para pruebas:

test("completa el checkout", async ({ page, request }) => {
  await page.getByRole("button", { name: "Pagar" }).click();

  await expect(page).toHaveURL(/\/pedidos\/[a-z0-9-]+/);
  await expect(page.getByRole("heading", { name: "Pedido confirmado" })).toBeVisible();

  const orderId = await page.getByTestId("order-id").textContent();
  const response = await request.get(`/api/test/orders/${orderId}`);

  expect(response.ok()).toBe(true);
  expect(response.status()).toBe(200);
  expect(await response.json()).toMatchObject({ state: "created" });
});

El endpoint de lectura es solo un ejemplo. No expongas datos internos al navegador del usuario solo para facilitar una prueba. Si la API no existe, comprueba la consecuencia mediante la interfaz, una cola de pruebas u otro artefacto seguro que el sistema ya produzca.

Cápsula de cita: Una prueba de Playwright generada por IA puede ponerse en verde al comprobar solo un toast, una redirección o un locator presente. La documentación de Playwright recomienda aserciones que esperan el estado previsto. Para evitar un falso positivo, la prueba también debe confirmar la consecuencia de negocio que el usuario debería observar.

El contrato va antes del archivo .spec.ts

Empieza con una frase que describa la regla, no la implementación. El contrato debe decir quién inicia el flujo, qué estado debe existir antes, qué acción ocurre y qué evidencia confirma el resultado. Esa frase se convierte en el criterio para revisar el archivo .spec.ts generado por el agente.

## Checkout aprobado

- Dado: un carrito con un producto disponible y un usuario autenticado.
- Cuando: el usuario confirma un pago aprobado.
- Entonces: el pedido aparece como creado, recibe un identificador y el carrito queda vacío.
- No demuestra: solamente la presencia de un toast o un cambio de URL.

Playwright ofrece agentes planner, generator y healer para explorar una aplicación, crear pruebas y proponer reparaciones. La documentación también conserva un seed test, un plan legible y archivos auditables en el flujo. El agente puede completar el esqueleto, pero el equipo decide si la aserción representa la regla.

Usa esta lista antes de revisar detalles de estilo:

Pregunta Señal aceptable Señal de alerta
¿La prueba conoce la intención? El nombre y el plan describen un resultado. El nombre repite el botón pulsado.
¿La acción llega al estado correcto? La prueba comprueba el destino y la consecuencia. La prueba se detiene en el primer toast.
¿La aserción puede fallar? Un camino roto produce un fallo real. El locator es opcional o nunca se usa.
¿Los datos están aislados? El fixture y el usuario pertenecen a la prueba. La prueba depende del estado dejado por otra.
¿La reparación se puede revisar? El agente propone un diff pequeño. El healer cambia la expectativa en silencio.

El último punto merece atención. Arreglar un locator es distinto de cambiar el resultado esperado. Lo primero puede acompañar un cambio de interfaz. Lo segundo puede ocultar una regresión. La diferencia debe aparecer en el pull request y en el informe de CI.

El contrato también conecta con los evals de PR para frenar agentes de código. Una prueba E2E cubre el flujo completo, pero la regla de negocio también puede necesitar una prueba de integración o una lectura controlada del servicio.

Locators, aserciones y estado forman tres comprobaciones

La verificación necesita tres capas. Primero, confirma que el locator describe el elemento tal como lo encuentra el usuario. Después, usa una aserción que espere al estado. Por último, comprueba el efecto que existe más allá del elemento utilizado para iniciar la acción.

Playwright recomienda locators orientados al usuario, como getByRole, getByLabel y getByTestId, en vez de cadenas frágiles de CSS o XPath (Playwright, buenas prácticas, consultado el 28/07/2026). Eso no vuelve buena una prueba automáticamente. Un locator semántico también puede apuntar al elemento equivocado si la aserción es débil.

test("actualiza la dirección del perfil", async ({ page }) => {
  await page.getByLabel("Calle").fill("Calle de las Flores, 10");
  await page.getByRole("button", { name: "Guardar dirección" }).click();

  await expect(page.getByRole("status")).toHaveText("Dirección guardada");
  await expect(page.getByLabel("Calle")).toHaveValue("Calle de las Flores, 10");
  await expect(page.getByTestId("profile-address")).toContainText("Calle de las Flores, 10");
});

Aquí, el status indica que la operación fue aceptada, el campo muestra el valor local y el resumen del perfil confirma el estado visible. En un sistema con persistencia asíncrona, añade una lectura segura o vuelve a abrir la página en un contexto nuevo para no comprobar solo la memoria del navegador.

No conviertas cada detalle en una aserción. El objetivo es probar el contrato, no congelar toda la estructura HTML. Evita también waitForTimeout como reparación automática. Si el agente no puede explicar qué condición debe esperar, el problema está en la prueba o en el producto, no en la falta de una pausa arbitraria.

Cápsula de cita: Los locators orientados al usuario hacen que una prueba resista mejor los cambios internos, pero no eliminan los falsos positivos. La verificación completa combina una acción, una aserción web-first y una consecuencia de negocio observable. Si el healer cambia la expectativa, el diff necesita revisión humana antes de entrar en la suite estable.

La evidencia debe viajar con la prueba

El mínimo es un archivo de prueba legible, el comando ejecutado, el resultado, un trace cuando falla y el diff propuesto por el agente. Esta colección permite saber si falló por una regresión, el entorno, un locator obsoleto o una expectativa incorrecta. Sin ella, CI solo entrega un color.

Configura el runner para conservar el trace en el primer retry de CI:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  forbidOnly: Boolean(process.env.CI),
  retries: process.env.CI ? 1 : 0,
  reporter: [["html", { open: "never" }]],
  use: {
    baseURL: "http://127.0.0.1:3000",
    trace: "on-first-retry",
    ...devices["Desktop Chrome"],
  },
});

Playwright documenta on-first-retry como una forma de recopilar un trace cuando el fallo se repite, sin grabar ese artefacto pesado en cada ejecución (Playwright, trace viewer, consultado el 28/07/2026). El trace muestra acciones, snapshots del DOM, red, consola y errores. No sustituye la revisión de la regla, pero reduce las conjeturas sobre lo ocurrido.

En loops largos que cambian entre agente, navegador, logs y revisión, uso RemoteCode para llevar Claude Code y Codex más lejos con menos contexto repetido. Es una herramienta mía, así que la recomendación es editorial y está ligada al coste de llevar la evidencia, no a una promesa de que valide la prueba.

CI juzga el artefacto, no la historia

El camino más corto es tratar la prueba generada como código de pull request. El agente abre el archivo, CI ejecuta el flujo y un job publica los artefactos. La aprobación llega solo cuando la prueba demuestra el contrato y el diff del agente no cambia la expectativa sin revisión.

Una secuencia sencilla para un proyecto Node.js es:

npm ci
npx playwright install --with-deps chromium
npx playwright test tests/checkout.spec.ts --reporter=line
npx playwright show-report

Verifica localmente con un camino roto de forma deliberada. Quita temporalmente data-testid="order-id" o haz que la API de prueba devuelva state: "pending". La prueba debería fallar por la razón esperada. Restaura el comportamiento y confirma que vuelve a pasar. Esta pequeña mutación informa más que mirar solo el primer resultado verde.

En CI, guarda playwright-report y test-results cuando la ejecución falle. En un flujo con agentes, registra también el plan original, el hash del commit, el nombre del modelo o de la herramienta cuando esté disponible y el diff de reparación. No envíes credenciales, cookies ni payloads sensibles al informe.

Este artefacto complementa los evals de regresión para agentes de código: el eval pregunta si el patch conservó el comportamiento, mientras la prueba del navegador ofrece una prueba concreta para ese flujo.

Cápsula de cita: CI debe juzgar un archivo generado por la evidencia que produce, no por la prosa del agente. Playwright ofrece informes y traces para depurar fallos. Un gate fiable ejecuta el flujo, comprueba el resultado esperado, conserva los artefactos y bloquea cambios silenciosos en la expectativa.

Errores comunes al revisar pruebas de agentes

Un error común es aceptar una aserción que solo confirma que la interfaz reaccionó. Cambia mensajes temporales por estado persistido, confirmación en una pantalla independiente o una lectura controlada del servicio. Tampoco dejes que el healer edite la expectativa sin revisión. Un arreglo mecánico de locator es una cosa; cambiar lo que cuenta como éxito es otra.

Es fácil confundir un retry con fiabilidad. Playwright clasifica como flaky las pruebas que pasan solo después de un retry; repetir la ejecución ayuda a diagnosticar, pero no convierte la inestabilidad en una prueba (Playwright, retries, consultado el 28/07/2026). Un retry limitado debe generar una señal para el equipo, no esconder la causa.

El aislamiento suele olvidarse cuando el agente recibe solo la pantalla y el requisito. La documentación de buenas prácticas de Playwright recomienda separar los datos y el contexto de cada prueba para mejorar la reproducción y evitar fallos en cascada. Sin fixtures y precondiciones claras, el archivo puede pasar solo porque otra ejecución dejó estado en el entorno. La referencia completa aparece en la lista de fuentes.

La cobertura de líneas también puede engañar. Una prueba puede atravesar muchas funciones sin comprobar la decisión relevante. Relaciona el caso con el requisito, el riesgo y el resultado observable. La cobertura ayuda a localizar código sin pruebas; no decide si una aserción demuestra la regla.

Cuando la suite crece, registra esta evidencia en la observabilidad de agentes de código en CI. El nombre de la prueba, el commit, el intento y el artefacto forman una traza breve para separar fallos del producto, del entorno y de la reparación automática.

Límites de este enfoque

Ningún checklist evita todos los defectos. Una prueba E2E no demuestra todas las combinaciones de datos, no sustituye las pruebas unitarias ni garantiza que un servicio externo esté disponible. La validación tampoco detecta por sí sola una regla de negocio incorrecta. Solo hace que el error sea más difícil de ocultar.

Para pagos, permisos, migraciones, datos personales e integraciones con efectos externos, exige pruebas de contrato, un entorno descartable y aprobación humana. Un agente puede sugerir el caso y escribir el esqueleto, pero el equipo debe decidir si el escenario es seguro, determinista y representativo.

Los Playwright Test Agents sirven para explorar, generar y reparar pruebas, pero la documentación describe un flujo que sigue produciendo planes y archivos revisables. Usa esa separación como principio: automatiza la producción, conserva la prueba y deja explícitos los cambios de intención.

Ese es el mismo límite que defiende un harness de verificación para pull requests de agentes de código: cada paso puede ser rápido, pero el cambio final debe llegar pequeño, rastreable y verificable.

Preguntas frecuentes sobre pruebas de Playwright generadas por IA

¿Una prueba de Playwright generada por IA sustituye la revisión humana?

No. Un agente puede crear locators y aserciones válidos, pero no debería decidir por sí solo si el caso demuestra la regla del producto. La persona revisora debe comparar el requisito, el flujo, el estado final, los datos de prueba y el diff de reparación antes de añadir la prueba a la suite estable.

¿Cómo sé si una aserción de Playwright es débil?

Es débil cuando puede pasar sin confirmar la consecuencia principal. Un toast, una URL o un elemento visible pueden ser evidencias útiles, pero no bastan si el requisito implica persistencia, cálculo, permisos o envío. Añade una comprobación independiente y ejecuta un camino que debería fallar.

¿Puede el healer cambiar una prueba automáticamente?

Puede proponer una corrección mecánica, como actualizar un locator que cambió, siempre que el diff siga visible. No aceptes automáticamente cambios en el resultado esperado, la regla de negocio, la condición de error o el alcance del escenario. Esos cambios necesitan revisión humana y evidencia nueva.

¿Debo usar trace en cada ejecución?

No. En CI, on-first-retry conserva evidencia cuando una prueba vuelve a fallar, mientras que la grabación continua aumenta el coste de los artefactos. Durante el desarrollo, activa trace para un fallo concreto y desactívalo cuando entiendas la causa.

Fuentes consultadas

  • Playwright, "Playwright Test Agents", consultado el 28/07/2026, https://playwright.dev/docs/test-agents
  • Playwright, "Best Practices", consultado el 28/07/2026, https://playwright.dev/docs/best-practices
  • Playwright, "Assertions", consultado el 28/07/2026, https://playwright.dev/docs/test-assertions
  • Playwright, "Retries", consultado el 28/07/2026, https://playwright.dev/docs/test-retries
  • Playwright, "Trace viewer", consultado el 28/07/2026, https://playwright.dev/docs/trace-viewer-intro
  • Playwright, "Release notes", consultado el 28/07/2026, https://playwright.dev/docs/release-notes
  • GitHub, "Building and testing Node.js", consultado el 28/07/2026, https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing/nodejs