Probar funciones que usan fetch nativo de JavaScript en Angular requiere una estrategia distinta a la del HttpClient. Aquí aprenderás a generar pruebas unitarias para un servicio de categorías que usa fetch con async/await, cómo apoyarte en la IA para reutilizar patrones existentes y por qué conviene una librería especializada para hacer mocking del fetch.

Por qué fetch necesita un mocking diferente al HttpClient

Cuando trabajas con HttpClient, Spectator te resuelve la inyección de dependencias mediante createHttpFactory, y eso facilita interceptar las peticiones. Con fetch la historia cambia: no se importa de ninguna librería ni se inyecta, porque pertenece a las APIs globales del navegador y de Node.js.

¿Qué es un global en testing? Es una función o variable disponible en el entorno de ejecución sin necesidad de importarla, como fetch, window o console. Para mockearla en Jest la reasignas sobre el objeto global.

Esa diferencia obliga a suplantar fetch directamente sobre el objeto global, ya que no quieres que la prueba dispare una petición real a un servidor.

Qué tiene de especial el servicio de categorías

Dentro de domains/shared el servicio de category expone dos alternativas para listar datos:

• Un getAll clásico que devuelve un Observable usando HttpClient.
• Un getAll en versión Promise, implementado con fetch nativo y async/await.

La primera versión se prueba igual que cualquier servicio HTTP. La segunda es la interesante, porque exige una técnica específica de mocking.

Cómo reutilizar mocks de categorías entre productos y servicios

Antes de escribir las pruebas conviene dejar listo el archivo category.mock.ts. La idea es centralizar la generación de datos falsos para no duplicar lógica.

Un detalle clave: dentro del mock de producto ya existía un fake pequeño de categoría. En lugar de mantener dos versiones, se reutiliza la función generateSubCategory directamente desde el mock de categorías.

• Importas generateSubCategory en el mock del producto.
• Aceptas un parámetro opcional data para sobreescribir la categoría cuando lo necesites.
• Si no se envía nada, se generan los datos predeterminados.

Así evitas datos inconsistentes entre suites de pruebas y mantienes una sola fuente de verdad para las categorías falsas.

Cómo guiar a Cursor para generar pruebas basadas en otro spec

Los servicios suelen seguir patrones repetidos: un CRUD con create, read, update y delete. Aprovechando esa similitud, puedes pedirle a la IA que use un archivo de pruebas existente como plantilla.

El prompt usado fue claro: generar unit tests para category.service, validar fallas, agregar casos, y usar product.service.spec como guía en lugar de pedirle que se base en todo el codebase. Como contexto adicional se adjuntó el archivo category.mocks para que supiera generar categorías falsas con la función ya creada.

¿Por qué pasarle un spec como guía a la IA? Porque le das un patrón validado por ti. La IA replica la estructura, los nombres, el estilo de aserciones y reduce errores como inventar métodos que no existen.

El resultado fue notable: Cursor detectó que no existía category.service.spec, lo creó y replicó la forma de probar HTTP. Esta vez no se equivocó con el flush null ni con los estatus de error, porque tenía un ejemplo correcto del cual aprender.

Dónde tropezó la IA al probar la versión con Promise

Para el getAll basado en fetch, Cursor improvisó. Agregó un global.fetch mockeado manualmente y resolvió las promesas con esa estructura.

Funciona, pero tiene problemas:

• El typing queda raro y poco claro.
• Aparecieron usos extraños como rejects en contextos donde no aplica.
• No es código reutilizable entre múltiples archivos de prueba.

La prueba pasa al ejecutarla, pero el código no se entiende a primera vista y eso afecta el mantenimiento.

Qué librería simplifica el mocking de fetch en Jest

La recomendación es usar jest-fetch-mock, una librería disponible en NPM que estandariza la suplantación de fetch en Jest.

¿Qué hace jest-fetch-mock? Reemplaza el fetch global con una versión mockeable que te permite definir respuestas, errores y secuencias con una API limpia y reusable, sin tocar global.fetch manualmente.

Las ventajas frente a la solución improvisada por la IA:

• Sintaxis declarativa para devolver respuestas o forzar errores.
• Tipado correcto que evita warnings y código confuso.
• Reutilizable en cualquier servicio que use fetch.
• Lecturable para quien revise el spec por primera vez.

Una vez integrada, puedes pasarle esa implementación a la IA como nueva guía. Así, cada vez que aparezca otro servicio con fetch, Cursor usará jest-fetch-mock en lugar de volver a inventar el mocking global.

¿Has usado fetch en lugar de HttpClient en tus servicios de Angular? Cuéntame en los comentarios cómo manejas tus pruebas y si ya conocías esta librería.