Probar servicios en Angular es uno de los caminos más amables para iniciarte en unit testing, porque no dependen de la UI ni requieren simular interacciones de usuario. Aquí verás cómo configurar pruebas con Spectator y Jest, escribir tu primer test sobre un servicio de carrito y apoyarte en IA para descubrir edge cases que tu código aún no cubre.

¿Por qué empezar el testing por los servicios en Angular?

Los servicios suelen ser piezas limpias: encapsulan lógica, no se montan en el DOM y muchas veces no tienen dependencias externas. Eso los vuelve ideales para tu primer acercamiento a las pruebas unitarias.

En la clase se elige un cart service que solo usa signals y expone un método para agregar productos. No inyecta HttpClient ni otras dependencias de Angular, así que el setup es mínimo y puedes concentrarte en la mecánica del test antes de pasar a servicios más complejos [01:38].

¿Qué es un servicio fácil de testear? Uno que no inyecta dependencias externas, expone métodos puros o basados en signals y permite instanciarse sin configuración adicional.

¿Cómo configurar Spectator para probar un servicio?

Spectator ofrece un boilerplate específico para servicios que reduce el trabajo de configuración. La pieza clave es createServiceFactory, que arma una fábrica de instancias del servicio que vas a probar [00:32].

El patrón de uso se apoya en tres elementos:

• SpectatorService: el tipo que te permite acceder al servicio y a sus métodos.
• createServiceFactory: define qué servicio se va a instanciar.
• beforeEach: corre antes de cada prueba y crea una instancia nueva del servicio.

El detalle importante está en ese beforeEach: garantiza que cada test tenga un escenario aislado. En unit testing esto es fundamental, porque cada prueba debe vivir en su propio ambiente para que no se pisen entre sí ni arrastren estado [01:05].

¿Cómo nombrar el archivo de pruebas y correrlo en Jest?

El archivo de pruebas sigue la convención cart.service.spec.ts. Si olvidas el sufijo .spec, Jest no lo reconoce como archivo de test y no verás el check verde en consola, una pista clara de que algo no se ejecutó [04:47].

Para correr solo esa suite y no toda la batería del proyecto, puedes usar:

• ng test para correr todas las pruebas.
• ng test -t "NombreDelDescribe" para filtrar por el nombre que usaste en el describe.
• ng test --coverage para generar el reporte de cobertura en HTML.

¿Cómo escribir una prueba para agregar productos al carrito?

Una vez instanciado el servicio, el siguiente paso es probar comportamiento real. En la clase se escribe el caso should add a product to the cart [05:50].

La estrategia se apoya en un mock del producto, que es un objeto inventado que cumple con el typing del modelo Product y suplanta a un producto real para poder enviarlo al servicio. Cursor ayuda a completar campos obligatorios como price, rating, category, images, slug y creationAt, este último como string y no como Date [06:50].

Con el mock listo, la prueba hace tres cosas:

1. Llama al método para agregar el producto al carrito.
2. Verifica que el signal cart tenga un elemento.
3. Comprueba que el total sea igual al precio del producto agregado, por ejemplo 10.

¿Qué es un mock en testing? Es un objeto falso que imita la estructura de un dato real para inyectarlo en una prueba sin depender de datos externos.

¿Conviene meter varios expects en un mismo test?

Puedes validar el cart y el total dentro del mismo bloque o separarlos en pruebas independientes. La regla práctica: si ambos expects describen el mismo comportamiento, agrúpalos; si describen reglas distintas, sepáralos para que el reporte sea más claro.

¿Cómo usar IA para generar más casos de prueba y descubrir edge cases?

Una sola prueba no basta. Con el servicio y el archivo spec ya configurados, puedes pasar al modo agente de Cursor y pedirle que genere casos adicionales. El prompt usado en clase es deliberadamente simple: generar unit test para CartService y edge cases [10:11].

Para código, la recomendación es usar Claude 3.5, aunque también funcionan GPT-4 o modelos de razonamiento como los de DeepSeek [11:00].

La IA propuso una suite agrupada con describe y aportó variantes interesantes:

• Inicializar el carrito vacío y verificar que total sea cero.
• Agregar dos productos con precios distintos (10 y 20) y validar que el total sea 30.
• Probar productos con precio cero, que no deben afectar la suma.
• Manejar números decimales o flotantes.
• Enviar un precio en -10, un caso que el servicio no protege.

Ese último caso es revelador: la lógica actual suma cualquier valor, así que un precio negativo da un total negativo. La IA no solo escribe pruebas, también expone reglas de negocio que faltan en tu servicio. Tal vez quieras añadir una validación que rechace productos con precio menor o igual a cero antes de agregarlos al carrito [13:28].

Al ejecutar la suite ampliada, las nueve pruebas pasaron correctamente, dejando el código del cart service mucho mejor cubierto que con la prueba inicial [14:00].

¿Cómo escribir un buen prompt para generar pruebas con IA? Da contexto del servicio y del archivo spec, pide explícitamente edge cases y revisa cada caso generado antes de aceptarlo.

¿Qué sigue después de cubrir el servicio del carrito?

Ya tienes el flujo completo: setup manual con Spectator, primera prueba escrita por ti y una suite ampliada con ayuda de IA. El siguiente paso es ordenar el mocking, porque cuando la IA genera muchos casos tiende a duplicar objetos mock. Crear una función reutilizable para construir productos de prueba simplifica el código y le da a la IA un patrón claro para seguir.

¿Qué edge case sumarías tú al cart service? Cuéntame en los comentarios cómo lo validarías.