Generar unit tests con AI cambia la forma en que escribes pruebas en Angular: ya no tienes excusa para saltarte el testing, porque herramientas como Cursor o GitHub Copilot pueden analizar tu código y proponer casos automáticamente. Pero ojo, sin contexto y criterio, la AI te genera pruebas que no sirven.

¿Por qué usar AI para escribir unit tests?

La AI lee tu código como texto y entiende qué hace cada función, así que puede sugerir escenarios de prueba que tú quizá no imaginaste. Eso eleva tu productividad y te ayuda a cubrir más casos sin escribirlos línea por línea.

Ahora, esto no significa apagar el cerebro. La AI funciona como un Copilot: alguien que te acompaña, pero a quien tienes que guiar. Si no conoces Jest, Spectator o Angular, no vas a poder distinguir un test bueno de uno inventado.

¿Qué es Spectator? Es una librería para hacer testing en Angular que simplifica el montaje de componentes y servicios. La AI la detecta automáticamente cuando ya está en tu codebase.

¿Cómo se comporta la AI cuando le das poco contexto?

Si solo escribes un comentario como edge cases dentro de tu archivo de prueba, la AI empieza a inferir casos a partir de lo poco que ve [3:20]. A veces acierta, a veces alucina.

Por ejemplo, en un pipe llamado reverse que recibe un string, la AI propuso estos escenarios:

• Retornar empty string si el input es vacío. Caso válido y útil.
• Recibir un número como parámetro. Caso inválido, porque el pipe tiene tipado fuerte y solo acepta string.
• Recibir un null. Caso inválido por la misma razón.

El único test que sobrevivió fue el del string vacío. La AI no estaba siendo consciente del tipado fuerte de TypeScript en Angular, y por eso generó pruebas que ni siquiera compilan.

¿Cómo guiar a la AI en modo agente para obtener mejores tests?

Aquí entra el modo agente, disponible tanto en Cursor (dentro de la pestaña Composer) como en VS Code con GitHub Copilot. El agente analiza más profundo, ejecuta el código, detecta fallos y refina la propuesta.

El flujo que funciona bien es este:

1. Abrir el Composer en modo agent, no en modo chat.
2. Pasar como contexto el archivo del pipe y el archivo de pruebas existente, usando drag and drop.
3. Escribir un prompt sencillo pero claro, como Generate unit test for this Angular pipe.
4. Dejar que el agente analice, ejecute y proponga.

Con ese contexto, el agente detecta que el proyecto usa Spectator y mantiene el mismo estilo de pruebas que ya tenías. Eso es clave: alimentarlo con buenos ejemplos previos para que replique el patrón [7:40].

¿Qué tipo de casos genera el agente con buen contexto?

En la prueba del reversePipe, el agente propuso casos mucho más sólidos:

• Strings largos con varias palabras.
• Strings con espacios intermedios.
• Strings con caracteres especiales.
• Números pasados como string, respetando el tipado.
• String vacío como caso límite.

También intentó probar la clase del pipe de forma aislada, sin Spectator. Es una opción válida, pero en Angular conviene seguir usando Spectator porque refleja cómo el componente se usa realmente en producción, sobre todo cuando hay dependencias inyectadas.

¿Cuándo conviene usar Spectator en lugar de instanciar la clase directo? Siempre que pruebes algo que va a vivir dentro del ciclo de Angular: componentes, pipes en plantillas o servicios con inyección. Spectator simula ese entorno.

¿Cómo los tests con AI te ayudan a optimizar tu código?

Después de correr ng test con coverage, pasaste de una sola prueba a seis, y el reporte mostró el pipe ejecutado 5X, es decir, cinco veces o más según los casos.

Y aquí viene lo interesante: los nuevos casos te revelan oportunidades de mejora. El caso del string vacío deja una pregunta obvia. ¿Para qué hacer un split, un reverse y un join si el valor está vacío? Puedes agregar un if al inicio:

typescript if (value === '') { return ''; }

Esa optimización pequeña no la habrías visto sin los nuevos casos de prueba. La AI no solo escribe tests, también te empuja a pensar tu código desde otros ángulos.

¿Qué tareas de testing puedes delegar y cuáles no?

• Unit tests: muy buen candidato, porque el contexto está acotado al archivo y sus dependencias directas.
• End-to-end tests: más complicado, porque requieren entender flujos completos, navegación, datos de backend y estados del sistema.
• Revisión de calidad de los tests generados: esto sigue siendo tuyo. Tienes que validar que los escenarios tengan sentido y que no haya parámetros alucinados.

Delegar no es desentenderse. Es saber Jest, saber Spectator, saber Angular, y usar la AI para amplificar tu alcance. ¿Tú ya estás usando agentes para escribir tus pruebas? Cuéntame en los comentarios cómo te ha ido y qué prompts te están funcionando.