Cuando un componente Angular tiene varias dependencias inyectadas, las pruebas unitarias se complican rápido. Aquí verás cómo testear un product detail con múltiples servicios usando Spectator, Jest y mock providers, una técnica clave para desarrolladores frontend que buscan cobertura real sin escribir código innecesario.

El reto es claro: tu componente no solo depende de un product service, también consume cart service y meta tag service. Y necesitas probar interacciones como agregar al carrito sin acoplarte a la lógica interna de cada servicio.

Cómo inyectar múltiples dependencias con mock providers en Spectator

La estrategia cambia según lo que quieras controlar de cada servicio. No todos los mocks necesitan el mismo nivel de detalle.

En el caso de product service, sí queríamos definir un valor inicial para que el observable resolviera de inmediato. Pero con cart service y meta tag service, el mock provider por defecto de Spectator basta. [2:30]

¿Qué hace mockProvider en Spectator? Crea automáticamente espías sobre todos los métodos del servicio inyectado. No necesitas definir cada función a mano si solo quieres verificar que fueron llamadas.

Esto significa que puedes dejar la inyección plana, sin pasar parámetros, y Spectator se encarga de generar los spies para que luego puedas hacer aserciones sobre las llamadas.

Cuándo definir un valor inicial vs dejar el mock por defecto

La diferencia es funcional, no estética:

• Si el servicio se ejecuta al inicializar el componente y necesita devolver datos, define el valor inicial.
• Si el servicio se ejecuta tras una interacción del usuario, como un clic, el mock por defecto es suficiente.
• Si solo te interesa verificar que un método fue llamado, no inyectes implementaciones, deja que Spectator espíe.

Cart service entra en la segunda categoría: solo se llama cuando el usuario presiona add to cart, así que no requiere setup adicional.

Cómo probar el clic en add to cart sin probar el carrito completo

La prueba que escribimos verifica que al hacer clic en el botón, el método addToCart del servicio fue invocado con el producto correcto. Nada más.

¿Por qué no probar que el producto realmente entra al carrito? Porque esa es responsabilidad del cart service, no del componente. Cada unidad debe testear lo suyo.

El flujo dentro del it('debería agregar un producto') queda así:

1. Localiza el botón con byTestId('add-to-cart').
2. Ejecuta el clic con el helper de Spectator.
3. Verifica con toHaveBeenCalledWith que el servicio recibió el producto mockeado.

Un detalle importante: tras el clic, no necesitas llamar manualmente a la detección de cambios. Spectator sincroniza la vista automáticamente después de eventos, lo que reduce el ruido en tus pruebas.

¿Por qué usar data-test-id en lugar de selectores CSS? Los test IDs desacoplan tus pruebas del estilo y la estructura visual. Si cambias clases o etiquetas HTML, el test sigue funcionando porque busca un identificador semántico.

Cómo reusar la inyección del servicio en varias pruebas

La buena práctica es obtener el servicio una sola vez con inject(CartService) al inicio del bloque de pruebas y reutilizar esa referencia. Evitas repetir código y mantienes consistencia entre los it.

Cuando tipas el resultado de byTestId, puedes especificar HTMLButtonElement para que el linter y Prettier dejen de reclamar. Aunque también puedes pasar el test ID directamente al método de clic y dejar que Spectator falle si no lo encuentra.

Qué herramientas usamos y por qué importa el contexto en la IA

El stack del curso combina Jest, Spectator y Angular, apoyado en inteligencia artificial para acelerar la escritura de pruebas. Aunque Jest aún no tiene soporte oficial al 100 % del equipo de Angular, el setup manual funciona sin problema en cualquier proyecto.

Spectator también es compatible con Jasmine y, a futuro, con Vitest. Pero Jest sigue siendo el framework más popular en el ecosistema, así que la elección tiene sentido para la mayoría de equipos.

• Jest: ejecutor de pruebas con buen rendimiento y mocking nativo.
• Spectator: librería que reduce el boilerplate de TestBed y simplifica la creación de hosts.
• AI: asistente para generar casos base, siempre supervisado.

La lección sobre IA es directa: las language models leen tu código y generan pruebas, pero a veces proponen matchers que no existen en tu setup o flujos innecesarios. Necesitas experiencia para reguiarlas y un buen code base para que el contexto sea útil. [9:15]

Qué cobertura buscar y qué falta por explorar

El reto que queda abierto es alcanzar al menos 80 % de cobertura en tu proyecto, complementando con la documentación de Spectator para directivas, pipes y otros artefactos que no cubrimos en profundidad.

Entre los casos más comunes que ya viste están: componentes con y sin inyección de dependencias, pruebas de integración, uso de test IDs y mocking de HTTP. Con esa base puedes abordar la mayoría de escenarios reales en aplicaciones Angular.

¿En qué parte de tu suite de pruebas crees que la IA te ayudaría más? Cuéntalo en los comentarios.