Testing frontend con IA: un flujo completo, no solo generación de código

Si alguna vez le has pedido a un agente de IA que te escriba un test y has acabado viéndolo ejecutarlo, fallar, y luego retocarlo hasta hacerlo pasar —incluso cuando la implementación no era correcta— este artículo es para ti.

La IA ya escribe una parte importante del código frontend que pasa por mis manos. Eso ha desplazado el cuello de botella: lo difícil ya no es producir, es producir con la confianza de que lo que generas sigue funcionando mañana. El testing frontend con IA ha pasado de ser algo que ocurre después a formar parte del mismo flujo en el que se escribe el código. Y eso cambia mucho más de lo que parece.

Cuando empecé a trabajar con TWD (Test While Developing), la idea era exactamente esa: tests que se ejecutan en el navegador, contra tu aplicación real, mientras desarrollas. Lo que ha cambiado en los últimos meses es que el flujo entero —desde la configuración hasta la documentación visual del suite— vive ahora dentro de una serie de skills para Claude Code. Seis pasos, una sola filosofía.

El problema: la IA escribe tests, pero no los tuyos

Cuando un agente escribe un test sin contexto, el resultado suele parecerse en todos los proyectos. Funciona en abstracto y sigue convenciones generales, pero casi nunca encaja en tu codebase.

No sabe cómo está estructurada tu aplicación, qué se mockea y qué se ejecuta contra el backend; cómo funciona tu auth ni qué selectores usa el resto del suite. Lo que produce parece correcto, pero exige otros veinte minutos de retoques antes de poder hacer commit.

La filosofía detrás de TWD se reduce a una frase:

Test what you own, mock what you don’t.

Aplicada al flujo con IA, esa idea se traduce en un requisito muy concreto: el agente necesita un mapa de tu proyecto. Estructura, mocks, auth, módulos de terceros, patrones de assertion. Sin eso, lo que genera es genérico, y los tests genéricos no aportan confianza, aportan ruido.

Por eso el primer paso del flujo es darle a la IA ese contexto en un formato que pueda releer en cada interacción, porque es la diferencia entre un agente que improvisa y uno que reproduce las reglas que tu equipo ya respeta. En proyectos donde llevamos años acompañando a equipos de frontend, hemos visto el mismo patrón: la calidad del output del agente sube en cuanto deja de adivinar el contexto y empieza a leerlo de un sitio fijo.

Cómo funciona el flujo completo de testing frontend con IA

El flujo está pensado para usarse en orden. Cada paso resuelve un problema distinto y deja preparada la siguiente etapa.

1. /twd:setup — Analiza tu proyecto, te hace unas pocas preguntas sobre auth, mocks y dependencias, y genera .claude/twd-patterns.md. Ese archivo es el contrato entre tú y el agente: a partir de ahí, todos los tests que escriba tienen que respetarlo.
2. /twd — Escribe el test, lo manda al navegador a través de un relay WebSocket, lee el resultado en texto plano y, si falla, lo corrige y lo vuelve a ejecutar. Sin capturas de pantalla, sin volcados del DOM. El bucle escribir-ejecutar-corregir consume una fracción de los tokens que necesita cualquier otra herramienta de testing con IA.
3. /twd:ci-setup — Detecta la configuración de tu proyecto y genera un workflow de GitHub Actions usando la action oficial de twd-cli. Cobertura, contract validation y Puppeteer ya vienen resueltos.
4. /twd:test-gaps — Cruza tus rutas con tus archivos de test y clasifica cada una como tested, partially tested o untested. Las rutas con mutaciones, permisos o flujos de pago aparecen primero, marcadas como HIGH risk.
5. /twd:test-quality — Puntúa cada archivo de test en cuatro dimensiones (cobertura de journey, profundidad de interacción, calidad de assertions, casos límite) y devuelve sugerencias accionables.
6. /twd:test-flow-gallery — Genera diagramas de Mermaid y resúmenes en lenguaje natural a partir de tus tests, para que producto y QA puedan leer la cobertura sin abrir un editor.

Por qué el agente también ejecuta los tests

La mayoría de herramientas de generación de tests con IA hacen lo más fácil: producen código. Te entregan un archivo y lo ejecutan muchas veces contra un jsdom, o lo lanzan a través de una herramienta como Playwright donde el bucle de feedback se mide en minutos. Y cuando un test falla, el agente acaba con frecuencia retocando el test hasta que pase —en lugar de arreglar la implementación— solo para que el suite vuelva al verde.

Con /twd ese paso no se delega. El agente envía cada test al navegador a través de twd-relay, una conexión WebSocket entre Claude Code y el sidebar de TWD que corre dentro de tu app. El test se ejecuta contra el DOM real, con los mocks reales, con el árbol de componentes real. El resultado vuelve como texto: pasó, falló, y en caso de fallo, qué dijo la consola.

Eso tiene dos consecuencias prácticas. La primera es que el consumo de tokens se mantiene bajo —y esto es lo que hace que el bucle sea viable—, porque el agente no procesa capturas ni serializaciones gigantes del DOM. La segunda es que cuando un test no pasa a la primera, el agente puede leer el error, ajustar la query del selector o el shape del mock, y reintentar de inmediato.

El bucle tiene un límite: si después de tres intentos el test sigue rojo, se marca como it.skip y se deja un comentario en el archivo. No bloquea el resto del suite y, sobre todo, no esconde el fallo. Eso es lo contrario de lo que hacen muchos agentes, que retocan el test hasta hacerlo pasar a costa de lo que sea; aquí, cuando el test no pasa, lo que se cuestiona es la implementación, y tú decides si la arreglas, si revisas el test o si lo dejas como recordatorio para más tarde. Un agente que silencia los tests que no logra arreglar es peor que uno que no los escribe. Esa transparencia es la que hace que, después de unas semanas, confíes en lo que el agente te entrega.

De «tenemos tests» a «tenemos buenos tests»

Que el suite esté en verde no significa que estés cubierto. Lo aprendí cuando un bug llegó a producción en una ruta que tenía una métrica de cobertura aceptable y, al revisarla, descubrí que el único test que la tocaba se limitaba a comprobar que el heading se renderizaba.

/twd:test-gaps está pensado para ese momento exacto. Recorre tus rutas, las cruza con tus tests, y separa lo que está realmente cubierto de lo que solo tiene un smoke test. Una ruta de checkout que se visita pero nunca envía formulario aparece como partially tested, marcada como HIGH risk. La salida es una lista priorizada por riesgo, no un porcentaje.

Una vez identificadas las zonas débiles, /twd:test-quality puntúa los tests existentes en cuatro dimensiones con peso distinto:

• Journey coverage (35 %) — ¿el test recorre un flujo completo o se queda en el primer render?
• Assertion quality (25 %) — ¿comprueba el payload de la API y el estado resultante, o solo que un botón es visible?
• Interaction depth (20 %) — ¿hay variedad real de interacciones, o todo son clics?
• Error and edge cases (20 %) — ¿qué pasa cuando el formulario está vacío o la API responde 500?

Cada archivo recibe una nota de la A a la D y dos o tres sugerencias concretas. Esas sugerencias se convierten directamente en el brief para /twd, que reescribe el test apuntando a los huecos detectados. Diagnóstico y reparación viven en el mismo flujo, sin tener que traducir manualmente «la calidad de las assertions es débil» a código nuevo.

El cierre del flujo es /twd:test-flow-gallery, que toma esos tests y los convierte en diagramas de Mermaid y resúmenes en lenguaje plano, colocados junto a cada archivo. Producto deja de preguntar «¿estamos testeando el checkout?» porque puede abrir el flujo y verlo. QA detecta huecos sin leer una línea de código.

Lo que viene después

El flujo completo de testing frontend con IA está disponible como plugin abierto en el repositorio de twd-ai en GitHub, y la documentación general de TWD vive en twd.dev. En Orbitant llevamos meses afinando este flujo en proyectos reales, y lo que estamos explorando ahora es cómo conectarlo con el resto de la cadena: desde la generación inicial de componentes hasta los entornos de preview y los reportes de cobertura que el producto consume cada semana.

Si parte de tu código frontend ya lo está escribiendo un agente, este es el siguiente paso lógico. No para que la IA escriba tests, que eso ya lo hace cualquier herramienta, sino para que los escriba siguiendo tus convenciones, los ejecute en tu navegador real y deje un rastro legible para todo el equipo.