¿Qué es Nock? Simulación de peticiones HTTP en Node.js (con una alternativa sin código)

Si tus pruebas de Node.js fallan porque una API de terceros está caída, lenta o con límites de velocidad, no tienes un problema de código. Tienes un problema de dependencia. La solución es simular la capa HTTP para que tus pruebas unitarias se ejecuten de la misma manera cada vez, y nock es el paquete npm al que la mayoría de los desarrolladores de Node recurren. Esta guía explica qué es nock, muestra un pequeño ejemplo funcional y cubre dónde un servidor de prueba simulado compartido encaja mejor que la intercepción en proceso. Para la referencia completa de la biblioteca, el repositorio de GitHub de nock es la fuente de verdad.

¿Qué es nock?

nock es una biblioteca de simulación de servidor HTTP y de expectativas para Node.js. Funciona anulando los módulos http y https de Node en tiempo de ejecución, por lo que cualquier solicitud saliente que haga tu código puede ser interceptada y respondida con una respuesta predefinida. Nada sale de tu máquina. La llamada de red nunca ocurre.

Eso importa para las pruebas unitarias. Cuando pruebas una función que llama a una API externa, no quieres acceder al servicio real. Las llamadas reales son lentas, cuestan dinero, pueden fallar por razones no relacionadas con tu código y hacen que tu suite de pruebas no sea determinista. nock te permite decir "cuando mi código hace una solicitud GET a esta URL, devuelve este JSON exacto con este código de estado". Tu prueba luego verifica cómo tu función maneja esa respuesta.

nock es solo para Node.js. Se conecta a la pila HTTP nativa, por lo que funciona con fetch, axios, got, node-fetch y cualquier otra cosa construida sobre http/https. Tiene millones de descargas semanales y ha sido una opción predeterminada para las pruebas de backend durante años. Lo instalas como una dependencia de desarrollo porque solo se ejecuta en pruebas, nunca en producción.

Un pequeño ejemplo de nock

Digamos que tienes una función que obtiene un usuario de una API. Aquí está la función:

// user-service.js
export async function getUser(id) {
  const res = await fetch(`https://api.example.com/users/${id}`);
  if (!res.ok) throw new Error(`Request failed: ${res.status}`);
  return res.json();
}

Ahora, aquí hay una prueba que usa nock para interceptar la solicitud:

// user-service.test.js
import nock from 'nock';
import { getUser } from './user-service.js';

test('returns the user when the API responds', async () => {
  nock('https://api.example.com')
    .get('/users/42')
    .reply(200, { id: 42, name: 'Ada Lovelace' });

  const user = await getUser(42);
  expect(user).toEqual({ id: 42, name: 'Ada Lovelace' });
});

Léelo de arriba a abajo. nock('https://api.example.com') establece el host que deseas interceptar. .get('/users/42') coincide con el método y la ruta. .reply(200, {...}) define el estado y el cuerpo a devolver. Cuando se ejecuta getUser(42), la llamada de red real se sustituye y se devuelve tu respuesta predefinida.

Puedes simular errores de la misma manera, que es la parte que la gente olvida probar:

test('throws when the API returns 500', async () => {
  nock('https://api.example.com')
    .get('/users/99')
    .reply(500);

  await expect(getUser(99)).rejects.toThrow('Request failed: 500');
});

Probar la ruta de error es donde la simulación demuestra su valor. No puedes hacer que una API en vivo devuelva un 500 bajo demanda de manera confiable, pero puedes simular uno en una sola línea. Si la simulación de errores es tu objetivo principal, este tutorial sobre cómo simular una respuesta de error interno del servidor 500 profundiza más.

Características útiles de nock que debes conocer

Algunos métodos surgen constantemente una vez que vas más allá de lo básico.

• .persist() mantiene un interceptor activo en múltiples llamadas. Por defecto, nock elimina un interceptor después de que coincide una vez, lo cual es excelente para asegurar que una solicitud ocurrió exactamente una vez. Usa .persist() cuando el mismo endpoint es accedido repetidamente en una prueba.
• .times(n) coincide con la misma solicitud un número determinado de veces antes de que el interceptor expire.
• .delay(ms) simula una respuesta lenta para que puedas probar el manejo de tiempos de espera.
• RegExp matching (coincidencia de expresiones regulares) permite que el host o la ruta sea un patrón en lugar de una cadena fija, útil cuando los IDs o las cadenas de consulta varían.
• nock.cleanAll() borra todos los interceptores. Ejecútalo entre pruebas para que las simulaciones de una prueba no se filtren a la siguiente.

Un hábito que vale la pena adquirir pronto: asegúrate de que todas tus simulaciones se hayan usado realmente. Llama a scope.done() en un interceptor (o nock.isDone()) y la prueba fallará si una solicitud esperada nunca se ejecutó. Esto convierte una llamada perdida silenciosa en un fallo ruidoso.

Donde nock deja de ser la herramienta adecuada

nock está diseñado para un trabajo y lo hace bien: interceptar HTTP dentro de un único proceso de Node durante las pruebas automatizadas. En el momento en que tu necesidad cruza un límite de proceso, ese modelo comienza a tensarse.

Aquí está la limitación. Las simulaciones de nock viven dentro de tu archivo de prueba, en tu tiempo de ejecución, en tu lenguaje. Un desarrollador frontend no puede apuntar su navegador a tu configuración de nock. Un ingeniero móvil no puede acceder a ella desde un simulador. Tu equipo de QA no puede ejecutar verificaciones manuales contra ella. Una colección de Postman no puede alcanzarla. La simulación existe solo mientras tu proceso de Jest o Mocha está en ejecución, y solo para el código en ese mismo proceso.

Esto está bien para las pruebas unitarias y es exactamente para lo que está diseñado nock. Pero muchas situaciones reales necesitan una simulación que viva en un lugar al que todos puedan acceder:

• El frontend necesita construir contra un endpoint antes de que exista el backend.
• Tres equipos en diferentes repositorios necesitan ponerse de acuerdo sobre las mismas respuestas falsas.
• Quieres demostrar una integración sin un backend en vivo.
• Un tester quiere probar casos extremos manualmente, sin necesidad de código.

Para esos casos, quieres un servidor de prueba simulado, algo que escuche en una URL real y devuelva respuestas a cualquiera que lo llame. Si estás sopesando las dos ideas, servidor de prueba simulado vs servidor real y la explicación más amplia sobre simulación de API exponen las ventajas y desventajas.

nock vs un servidor de prueba simulado alojado (Apidog)

Piénsalo como dos capas en lugar de una competencia. nock maneja la intercepción dentro del código para pruebas unitarias. Una herramienta como Apidog te proporciona un servidor de prueba simulado compartido y basado en esquemas para todo lo que ocurre fuera de un único proceso de prueba. Muchos equipos usan ambos.

Apidog genera un servidor de prueba simulado directamente desde el diseño de tu API. Defines un endpoint y su esquema, y Apidog sirve respuestas realistas en una URL en vivo, con reglas de simulación inteligentes que producen datos plausibles a partir de nombres de campo y tipos. Sin arneses de prueba, sin configuración por prueba, sin bloqueo de idioma. Cualquiera con la URL obtiene las mismas respuestas.

Para ser claros sobre el alcance: Apidog no reemplaza a nock dentro de tus pruebas unitarias de Jest o Mocha. Si necesitas interceptar una llamada a fetch en una sola prueba y verificar el resultado, nock sigue siendo la herramienta adecuada. Apidog interviene cuando la simulación necesita una dirección a la que otras personas y otras herramientas puedan acceder. Para una visión práctica del lado del servidor, consulta la guía práctica para simular una API para pruebas. Puedes descargar Apidog y poner en marcha una simulación a partir de un archivo OpenAPI existente en unos minutos.

Otras alternativas a nock

nock no es la única biblioteca en este espacio, y la elección correcta depende de dónde se ejecuta tu código.

• MSW (Mock Service Worker) intercepta las solicitudes a nivel de red utilizando un service worker en el navegador y un interceptor de Node en el servidor. Las mismas definiciones de simulación funcionan en ambos, por lo que muchos equipos ahora lo usan por defecto para JavaScript full-stack. La documentación oficial de MSW explica el modelo.
• Los mocks manuales de Jest te permiten reemplazar un módulo como axios con uno falso. Esto es más simple que nock para un caso pequeño, pero te vincula a un cliente HTTP. El tutorial de mocking de Jest cubre el patrón.
• Los dobles de prueba integrados en el propio ejecutor de pruebas de Node o bibliotecas como Sinon pueden sustituir la función que realiza la llamada, aunque pierdes la coincidencia a nivel HTTP de nock.

La pregunta decisiva es siempre la misma. ¿Estás probando lógica dentro de un proceso, o necesitas una API falsa que viva en la red? nock y MSW responden a lo primero. Un servidor de prueba simulado alojado responde a lo segundo.

Preguntas frecuentes

¿Es nock gratuito?

Sí. nock es de código abierto bajo la licencia MIT y de instalación gratuita desde npm. Lo añades como una dependencia de desarrollo y lo usas en tu suite de pruebas sin costo alguno.

¿Funciona nock con fetch y axios?

Sí. Debido a que nock intercepta en la capa http/https de Node, funciona con cualquier cliente construido sobre esos módulos, incluidos el fetch nativo, axios, got y node-fetch. Escribes el mismo interceptor independientemente de cuál use tu código.

¿Puedo usar nock en el navegador?

No. nock es solo para Node.js porque parchea los módulos HTTP de Node, que no existen en el navegador. Para la simulación en el lado del navegador, usa MSW o apunta tu frontend a un servidor de prueba simulado alojado. Esta descripción general de APIs simuladas en JavaScript recorre las opciones del navegador.

¿Cuál es la diferencia entre nock y un servidor de prueba simulado?

nock intercepta las solicitudes dentro de tu proceso de prueba y nunca abre un puerto real. Un servidor de prueba simulado escucha en una URL real a la que cualquier cliente puede llamar. Usa nock para pruebas unitarias; usa un servidor de prueba simulado cuando el frontend, QA u otros equipos necesiten acceder a las mismas respuestas falsas.

Conclusión

nock es la opción fiable para la simulación HTTP en las pruebas unitarias de Node.js. Intercepta las solicitudes salientes en proceso, devuelve las respuestas que defines y hace que tu suite de pruebas sea rápida y determinista, incluyendo las rutas de error que no puedes activar contra una API en vivo. Sigue usándolo para eso.

Cuando la simulación necesita salir de tu archivo de prueba, cuando el frontend, QA u otro equipo tiene que acceder al mismo endpoint, recurre a un servidor de prueba simulado compartido. Apidog genera uno a partir del esquema de tu API y sirve datos realistas en una URL en vivo, para que todos construyan contra el mismo contrato antes de que el backend esté listo. Descarga Apidog y convierte tu especificación OpenAPI en una simulación funcional en minutos.