¿Qué es el API mocking? Herramientas, usos y ejemplos

¿Qué es el API mocking?

El API mocking consiste en sustituir una API real por una simulada que devuelve respuestas predefinidas. El cliente llama a las mismas URL y recibe el mismo formato de respuesta, pero nada llega al backend real: ni base de datos, ni efectos secundarios, ni la factura de un tercero. Como usted controla las respuestas, las pruebas son deterministas y puede provocar casos difíciles de reproducir a demanda, como un error 500 o una respuesta lenta.

Los mocks se usan para desarrollar un frontend antes de que exista el backend, para que las pruebas automáticas no dependan de servicios que pueden caerse y para comprobar que un cliente gestiona bien las respuestas documentadas. Un mock es una herramienta de desarrollo y pruebas, no un sustituto de probar la API real. Más en pruebas de API.

Cómo funciona el API mocking

Un servidor mock (o un interceptor dentro del proceso de pruebas) recibe una petición, la identifica por método, ruta, cabeceras o cuerpo y responde con una respuesta fija o calculada. Se apunta el cliente al mock cambiando la URL base, normalmente con una variable de entorno; un interceptor, en cambio, captura las llamadas salientes y no hace falta tocar el código.

// Dev: API_BASE=http://localhost:8000 (mock)
// Prod: API_BASE=https://api.example.com (real)
const API_BASE = process.env.API_BASE || 'https://api.example.com';
fetch(`${API_BASE}/users/42`);

Cuándo usar API mocking

• Trabajo de frontend antes de tener el backend. Se desarrolla contra el JSON acordado y después se cambia la URL base.
• Pruebas unitarias y de integración. Sin red y sin terceros poco fiables.
• Rutas de error. Devolver un 429, un 500 o un timeout cuando haga falta.
• APIs de pago o con límite de uso. No pagar ni ser limitado en cada ejecución de pruebas.
• Demos y trabajo sin conexión. Sin datos de producción y sin conexión.

Tipos de mocks de API

• Estático: siempre la misma respuesta.
• Dinámico: la respuesta depende de la ruta, la query string o el cuerpo.
• Grabado: respuestas reales capturadas una vez y reproducidas después.
• Basado en la especificación: generado a partir de un archivo OpenAPI, de modo que el mock sigue el esquema documentado (véase Swagger).
• Con estado: un POST crea algo que un GET posterior devuelve. Útil para flujos de extremo a extremo, pero costoso de mantener.

Herramientas habituales de API mocking

Ejemplo con MSW (sintaxis de la v2):

import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';

const server = setupServer(
  http.get('https://api.example.com/users/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Alice' });
  })
);
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Ejemplo con nock:

const nock = require('nock');
nock('https://api.example.com')
  .get('/users/42')
  .reply(200, { id: 42, name: 'Alice' });

Mock, stub, fake y spy

• Stub: devuelve una respuesta fija.
• Mock: un stub que además comprueba que se le llamó como se esperaba.
• Fake: una implementación real pero simplificada, como una base de datos en memoria.
• Spy: envuelve la llamada real y registra lo que se envió.

En el lenguaje cotidiano, "mocking" abarca los cuatro. Las diferencias estrictas solo importan en los frameworks de pruebas unitarias.

Errores frecuentes

• El mock se desvía de la API real. El proveedor cambia un campo, el mock no, las pruebas siguen en verde y producción falla. Genere los mocks desde la especificación o use contract testing, que comprueba ambos lados contra el mismo contrato.
• Probar solo contra mocks. Conserve algunas pruebas de integración contra una API de staging o real.
• Mocks demasiado permisivos. La API real valida la entrada y rechaza lo que el mock acepta.
• Solo el caso feliz. Añada errores, resultados vacíos, respuestas lentas y cuerpos mal formados. Más en errores comunes de mocking en pruebas de API (en inglés).
• Un mock que se convierte en un segundo backend. Si necesita su propia lógica de negocio, use un entorno de pruebas.

Mocks, pruebas de carga y monitorización

Una prueba de carga contra un mock mide el mock, no su servicio, así que no la use para demostrar que su API aguanta tráfico. Los mocks sí ayudan dentro de una prueba de carga cuando detrás de su servicio hay un tercero lento o con límites: sustituya esa dependencia para que el resultado refleje su propio código. La prueba de capacidad real se hace contra la API real en un entorno de staging, por ejemplo con las pruebas de carga de LoadFocus (scripts JMeter y k6).

Un mock no avisa de que la API real cambió después del despliegue. Eso lo hacen las comprobaciones programadas contra el endpoint real: la monitorización de API de LoadFocus llama a sus endpoints de forma programada (cada 5 minutos en el plan gratuito), comprueba código de estado, tiempo de respuesta y cuerpo, y avisa cuando algo falla. Relacionado: monitorización de API, endpoint de API, pruebas de regresión.

Preguntas frecuentes sobre API mocking

¿Qué diferencia hay entre un mock y una API de staging?

Un mock es local, rápido y está totalmente bajo su control. Una API de staging es un despliegue real del servicio sin datos de producción. Use mocks para pruebas unitarias y desarrollo, y staging para pruebas de integración y de extremo a extremo.

¿Debo simular todas las APIs externas en las pruebas?

En las pruebas unitarias, sí, para probar su código de forma aislada. En las de integración, conserve al menos algunas llamadas contra un servicio real o de staging para detectar problemas que un mock no muestra.

¿Cómo simulo respuestas dinámicas?

La mayoría de las herramientas calculan la respuesta a partir de la petición: WireMock ofrece plantillas de respuesta, Mockoon admite datos dinámicos y los handlers de MSW son funciones JavaScript normales.

¿Se puede simular GraphQL o gRPC?

GraphQL sí: MSW lo admite. Para gRPC hace falta una herramienta de mock específica, porque un mock HTTP normal no habla ese protocolo.

¿Cómo mantengo un mock sincronizado con la API real?

Genérelo desde la especificación OpenAPI siempre que pueda y añada pruebas de contrato o una comprobación programada contra el endpoint real, para que un cambio del proveedor rompa una prueba y no producción.