Lección 2 de 6 · 3 min
Automatización asistida por IA
El flujo que funciona en producción
Humano define el comportamiento, IA escribe el test, humano revisa el diff. La suite de 58 tests de este sitio se construyó exactamente así. La clave está en qué contexto recibe el modelo:
Escribe un test Playwright para: "el formulario de contacto muestra
error si el teléfono no es chileno válido".
Convenciones del proyecto (síguelas estrictamente):
- Locators: getByRole/getByLabel; jamás CSS ni XPath
- Assertions web-first (await expect(locator)...)
- Los tests viven en e2e/, un describe por página
- Fixture existente `contactPage` ya navega al formulario
[pega aquí un test existente del proyecto como referencia de estilo]
El test de referencia pegado al final es el ingrediente mágico: el modelo imita estilo con mucha más fidelidad de la que obedece instrucciones abstractas.
La revisión no es opcional
Un test generado y no revisado es peor que ningún test: da confianza falsa. La checklist de revisión del diff:
- ¿El test puede fallar? Pide al modelo el test y luego rompe la app a propósito (o pídele que te diga qué cambio lo haría fallar). Un test que pasa contra la app rota es decoración. Esta es LA revisión — las demás son detalles.
- ¿Asserta el comportamiento o la implementación? "El error es visible y nombra el campo" ✓; "el div tiene la clase error-red" ✗.
- ¿Inventó locators? El modelo a veces asume
data-testidque no existen. Corre el test, no lo leas solamente. - ¿Respetó las fixtures? O ¿duplicó un login manual que ya existía como fixture?
Mantenimiento: el segundo superpoder
Donde la IA brilla silenciosamente es en el mantenimiento masivo:
- Refactor de suite: "migra estos 12 tests de selectores CSS a getByRole" — minutos en vez de una tarde.
- Actualización tras un cambio de UX: pega el diff del componente y los tests afectados; pide la actualización coherente.
- Traducción entre frameworks: de Cypress a Playwright conservando la intención — sorprendentemente bueno, revisando siempre los intercepts→routes.
La barandilla institucional
Regla de equipo recomendada: ningún test generado se mergea sin haberlo visto fallar. Se implementa fácil: en el PR, un commit muestra el test en rojo contra el bug simulado y el siguiente lo muestra en verde. Caro de disciplina, barato comparado con una suite de mentira.
Ejercicio
Pide a un LLM un test para un formulario público usando el patrón de prompt (con convenciones + ejemplo de estilo). Córrelo, hazlo fallar rompiendo el input esperado y documenta: ¿el mensaje de fallo te dice qué se rompió sin abrir el test?