¿Quieres aprender a crear unit tests con ayuda de inteligencia artificial sin escribir cada prueba a mano? En esta práctica construimos tests para una aplicación usando Windsurf, pedimos una estrategia al modo chat de Cascade y validamos que el código respete los estándares definidos. Es ideal para quien ya programa con Next.js y quiere acelerar su flujo de testing.

La idea central es simple: antes de escribir pruebas, le preguntamos al modelo cuál es la mejor estrategia y dejamos que genere un plan por fases. Y aquí viene lo interesante, porque la IA no solo planifica, también ejecuta.

Por qué pedir una estrategia de testing antes de escribir código

En lugar de lanzarte a crear tests a ciegas, el primer paso es abrir Cascade, cambiar al modo chat y usar un prompt sencillo: dime la mejor estrategia para crear unit tests para este proyecto y crea el plan para hacerlo. Es muy parecido a lo que haríamos con un refactor.

El modelo lee los archivos del proyecto: el package.json, el header, el footer, y busca archivos TypeScript y TSX. Con eso arma una estrategia basada en el enfoque de testing piramidal.

¿Qué es el enfoque de testing piramidal? Es una estrategia que prioriza muchos tests unitarios en la base, menos tests de integración en el medio y pocos tests de interfaz arriba. Así cubres más código con pruebas rápidas y baratas de mantener.

Entre las librerías recomendadas aparecen React Testing Library con Jest, Jest DOM, User Event para interacciones del usuario y Mock Service Worker. Este último no lo usamos porque hay una clase específica dedicada a los mocks [00:48].

Cómo se organiza el plan de testing por fases

El modelo entrega un plan de implementación detallado dividido en fases, con tiempos estimados si lo hicieras manualmente. Esto te da una idea realista del esfuerzo.

• Fase uno: configuración base, entre una y dos horas. Incluye cómo quedaría el package.json, la configuración de Jest y el coverage threshold de cada item.
• Fase dos: tests de componentes de layout para el header y el footer, con el setup de Jest.
• Fase tres: tests de páginas, utilitarios y helpers, entre una y dos horas.

La métrica de cobertura objetivo es superar el 70% en cada item [02:37]. Para esta práctica solo ejecutamos la instalación de librerías y creamos dos tests: uno de componente y uno de página.

Qué significa el coverage threshold en Jest

El coverage threshold define el porcentaje mínimo de código que tus tests deben cubrir. Si configuras un umbral del 70% y tus pruebas cubren menos, Jest marca el resultado como fallido. Es una forma de forzar calidad en el equipo.

Cómo ejecutar la configuración base con el modo code

Aquí cambiamos de chat a code y le pedimos que ejecute la fase uno completa más un solo test de componente de la fase dos. El modelo toma acciones siguiendo su plan.

Modifica el package.json, agrega las librerías de testing, crea los archivos de configuración de Jest y además incluye utilidades de testing que no le pedimos, pero que consideró necesarias. Por eso conviene revisar siempre lo que genera. Se decidió por crear el test del header [04:12].

Después de modificar el package.json, toca instalar. Y aquí aparece un problema clásico.

¿Por qué falla npm install con librerías de testing en React? Suele ser por incompatibilidad entre la versión de React y las versiones de las librerías. La solución es usar npm install --legacy-peer-deps para ignorar o regularizar esos conflictos de dependencias.

Al correr la instalación con ese flag, las carpetas que estaban marcadas en rojo pasan a verde, señal de que ya están funcionales.

Qué hacer cuando un unit test falla

Al ejecutar npm run test del header, varios tests pasan pero uno falla: shows mobile menu button on mobile. El problema es que lo prueba en desktop y no en mobile [06:18].

Cada bloque describe agrupa tests y cada check verde es una prueba que pasó. Para avanzar en la práctica, hacemos un skip de ese test en lugar de resolverlo. Al volver a correr el comando, todos pasan y uno queda skippeado.

bash npm install --legacy-peer-deps npm run test

Esta decisión de saltar un test es pragmática: el objetivo era ver el flujo funcionando, no dejar la cobertura perfecta.

Cómo usar el arroba para agregar contexto en Windsurf

La feature estrella de esta práctica es el arroba dentro del prompt. Al escribir @, Windsurf despliega un menú para traer contexto local sin copiar contenido manualmente.

Puedes referenciar varios elementos:

• Páginas web completas.
• Ítems de código específicos.
• Archivos y directorios del proyecto.
• Documentaciones externas.

Para crear el test de la página del single blog, seleccionamos ese archivo con @ y también referenciamos el header test como ejemplo. El prompt queda limpio y con dos contextos distintos, sin pegar código ni rutas largas [08:05].

El modelo genera el test dentro de la carpeta del slug, la que Next.js usa para el individual del blog. Cubre el caso cuando el post existe con renderizado de título y metadata, cuando no existe con un mensaje de error, y hasta accesibilidad, con una cobertura esperada entre 90% y 97%.

Por qué revisar el código generado antes de confiar en él

Al correr npm run test completo, falla un test del blog post page: tiene los links a los posts relacionados. El mock no funciona al 100% y los list items llegan vacíos [09:52].

Además, el archivo test utils que la IA creó sin pedírselo tampoco se necesita, así que eliminamos esa carpeta. Tras skippear el test del slug que fallaba, los dos tests principales pasan y quedan dos pruebas skippeadas que luego puedes pedirle a Cascade que resuelva.

La lección es clara: la IA acelera el trabajo, pero tú validas. Revisa siempre los archivos y el código que va generando, porque suele crear cosas que no estaban en tu prompt.

¿Ya probaste referenciar archivos con el arroba? Cuéntame en los comentarios cómo lo usaste, qué resultados te dio y, si tuviste problemas con los unit tests, cuáles fueron y cómo los solucionaste.