Revisar tests escritos por IA: los 7 chequeos

Verde no significa protegido

La IA escribe tests rápido y que pasan. Ese es el problema: pasar no es lo mismo que proteger. Un test que no falla cuando la app se rompe es peor que no tener test, porque da confianza falsa.

Estos son los 7 chequeos para aprobar un test escrito o modificado con IA. Los ejemplos están en Playwright, pero aplican igual a Cypress o Selenium.

1. Rómpelo a propósito

Cambia el valor que el test dice proteger, o comenta esa línea del código, y córrelo. Tiene que ponerse rojo. Si sigue verde, no prueba nada.

Es mutation testing hecho a mano: introducir un error a propósito para ver si la suite lo detecta. La prueba final de la Sesión 2 se corrige exactamente así, contra versiones de la tienda con errores plantados.

2. Lee las aserciones, no el nombre

test('valida el pago con tarjeta', async ({ page }) => {
  // ...completa el checkout...
  await expect(page.getByRole('heading', { name: 'Gracias por tu compra' })).toBeVisible();
});

El nombre promete validar el pago; la aserción solo verifica que apareció un título. Un test que de verdad valida el pago revisa el resultado de negocio:

await expect(page.getByTestId('total-pagado')).toHaveText('$12.990');
await expect(page.getByTestId('estado-pedido')).toHaveText('Pagado');
await expect(page.getByRole('link', { name: 'Descargar comprobante' })).toBeVisible();

3. Busca cada selector en la app real

La IA genera selectores que suenan perfectos: getByTestId('checkout-submit-button'). Si ese data-testid no existe, el test falla, y alguien termina "arreglándolo" con lo primero que encuentra. Abre la app y confirma que cada locator existe. Prefiere roles y labels antes que CSS.

4. Revisa los datos

test@test.com y "1234" no encuentran bugs. Datos que se parecen a producción sí: un RUT con dígito verificador K, un monto con decimales, un nombre con ñ y tildes, una dirección sin comuna. Siempre sintéticos: nunca datos reales de clientes.

5. Caza las esperas fijas

await page.waitForTimeout(3000); // ¿por qué 3 segundos? Nadie sabe.

Una espera fija hace que el test pase hoy y falle mañana en una máquina más lenta. La forma correcta es esperar un estado, con aserciones que reintentan solas:

await expect(page.getByText('Pedido confirmado')).toBeVisible();

6. Pide el riesgo en una frase

Quien abre el PR escribe qué bug evitaría este test. "Que se cobre dos veces con doble clic" es un riesgo. "Para subir la cobertura" no lo es. Si nadie puede decirlo, el test no entra.

Es el chequeo que más enseña, sobre todo a quien recién empieza: obliga a pensar en lo que se protege y no solo en lo que se escribe.

7. Si se auto-reparó, lee el diff

Los agentes y las funciones de self-healing (el healer de Playwright, cy.prompt en Cypress) reparan tests que fallan. Si una reparación cambió un selector o, peor, un valor esperado, alguien tiene que leer el diff y entender por qué falló el test original. Un valor esperado que cambió solo es la forma más silenciosa de tapar un bug.

En la plantilla de PR

Los 7 chequeos van como checklist en la plantilla de pull request del repositorio, con una línea final: revisado y firmado por una persona con nombre. El checklist descargable de esta lección está listo para pegar.

Cierre del curso

Ya tienes lo que ninguna herramienta enseña: el criterio para decidir qué se automatiza, la arquitectura para que la suite aguante crecer, el Page Object sin monstruos, los datos aislados que hacen posible el paralelismo, el catálogo de anti-patrones, el flujo con CLI, CI y MCP, y el estándar para aprobar lo que escribe la IA.

Combínalo con tu herramienta: Playwright, Cypress o Selenium, y practica en el playground de automatización.

Comprueba lo aprendido en el quiz y suma el checklist a tu plantilla de PR en el reto final.