Un mock API es una API falsa que se comporta como una real. Acepta las mismas solicitudes, devuelve respuestas con la misma estructura y reside en una URL que puedes llamar, pero detrás de esa URL no hay una base de datos real, ni lógica de negocio, ni un servicio real. La respuesta es algo que definiste de antemano.
Eso suena trivial, y lo es. El valor proviene de lo que te permite hacer: construir y probar contra una interfaz antes de que la cosa detrás de ella exista o mientras la cosa real es demasiado lenta, costosa o poco confiable para llamar. Esta explicación define el término con precisión, separa un mock de las cosas con las que se confunde y establece la distinción estática versus dinámica que decide cómo se comporta un mock.
Qué es realmente un mock API
En esencia, un mock API es un mapa de solicitud a respuesta. Entra una solicitud. El mock la compara con las reglas que estableciste, elige una respuesta y la envía de vuelta. No hay computación intermedia a menos que la solicites.
Un mock tiene tres partes. Está la interfaz: las rutas, métodos y parámetros que acepta, que deben coincidir exactamente con la API real. Está la definición de la respuesta: los cuerpos, códigos de estado y encabezados que devuelve. Y está la lógica de coincidencia: cómo el mock decide qué respuesta obtiene una solicitud dada, desde una simple coincidencia de ruta hasta reglas que se ramifican en parámetros de consulta o encabezados.
Dado que la interfaz coincide con la API real, el código que llama al mock no sabe que es falso. Cambia la URL base y el mismo cliente se comunica con el servicio real. Esa intercambiabilidad es el objetivo principal. Para un tutorial práctico sobre cómo construir uno, consulta esta guía para simular una API para pruebas.
Ayuda ser preciso sobre lo que no es un mock API. No es un caché, porque un caché almacena respuestas reales y un mock las inventa. No es un sandbox, porque un sandbox de proveedor ejecuta lógica real y simplificada, mientras que un mock no ejecuta ninguna lógica en absoluto. Y no es un entorno de staging, porque staging es una implementación completa del sistema real. Un mock es más ligero que los tres: es solo la puerta de entrada de una API con respuestas predefinidas detrás, y nada más.
Mock versus stub
La gente usa "mock" y "stub" indistintamente, pero en las pruebas significan cosas diferentes.
Un stub es la idea más simple. Devuelve una respuesta predefinida a una llamada y nada más. Si le pides un usuario, devuelve un usuario fijo. Un stub no tiene opinión sobre cómo fue llamado.
Un mock, en el sentido estricto de las pruebas, también verifica la interacción. Puede afirmar que fue llamado, cuántas veces y con qué argumentos. Un mock puede hacer que tu prueba falle porque la llamada fue incorrecta, no solo proporcionar un valor.
En el trabajo diario con API, la línea es borrosa, y "mock API" generalmente cubre ambos. La lección útil: un stub responde, un mock responde y observa. Cuando tu prueba solo se preocupa por los datos que recibe tu código, una respuesta de tipo stub es suficiente. Cuando le importa si tu código hizo la llamada correcta de la manera correcta, quieres la verificación que añade un verdadero mock. Para un vocabulario más amplio, consulta la diferencia entre validación y verificación.
Dos términos más están relacionados. Un fake es una implementación funcional pero simplificada, como una base de datos en memoria utilizada en lugar de una real; tiene lógica, solo que menos. Un spy envuelve un objeto real y registra cómo fue llamado sin cambiar su comportamiento. Un mock API, tal como se usa el término en el desarrollo de API, es lo más parecido a un stub con verificación opcional, servido a través de HTTP en una URL real. No necesitas vigilar el vocabulario, pero conocer el espectro te ayuda a leer la documentación de pruebas sin perderte.
Mock API versus servidor real
Un servidor real y un servidor mock pueden residir en la misma URL y devolver el mismo JSON, por lo que la diferencia está en lo que sucede detrás del endpoint.
| Mock API | Servidor real | |
|---|---|---|
| Detrás del endpoint | Respuestas predefinidas | Lógica en vivo y una base de datos |
| Fuente de la respuesta | Reglas que escribiste | Calculada por solicitud |
| Datos | Fijos o generados | Reales, persistentes |
| Efectos secundarios | Ninguno | Escrituras, cargos, correos electrónicos |
| Velocidad | Rápida y constante | Varía con la carga |
| Corrección | Coincide con lo que definiste | Coincide con el comportamiento real |
Un servidor real te dice la verdad: ejecuta el código real y demuestra que el sistema funciona. También es lento, tiene estado y es capaz de producir efectos secundarios reales, por lo que una prueba contra él puede cargar una tarjeta o enviar un correo electrónico.
Un servidor mock te dice solo lo que le dijiste. Es rápido, libre de efectos secundarios y perfectamente predecible, lo que lo hace ideal para el desarrollo y la mayoría de las pruebas. Pero un mock puede estar equivocado y nunca saberlo, porque no ejecuta la lógica real. Por eso se mantienen algunas pruebas en el servidor real. La compensación se cubre en profundidad en servidor mock versus servidor real.
Mocks estáticos y dinámicos
Un mock devuelve su respuesta de una de dos maneras, y la elección determina cómo se siente usar el mock.
Un mock estático devuelve una carga útil fija. Escribes el JSON exacto una vez, y cada solicitud coincidente recibe ese mismo cuerpo. Los mocks estáticos son predecibles, lo que los hace fáciles de verificar. Su debilidad es el realismo: una única carga útil codificada no revelará un error en el código que falla con cadenas largas, arreglos vacíos o nulos inesperados.
Un mock dinámico genera la respuesta por solicitud. En lugar de un "id": "user_1001" fijo, produce un UUID nuevo en cada llamada. En lugar de un nombre, devuelve un nombre realista diferente cada vez. Los mocks dinámicos suelen impulsar esto con una gramática de generación de datos como Faker.js, de modo que un campo llamado email produce un correo electrónico y created_at produce una fecha. Son más realistas y mejores para exponer casos extremos, a costa de ser más difíciles de verificar con exactitud.
La mayoría de los equipos utilizan ambos. Mocks estáticos para pruebas unitarias con muchas aserciones donde se necesita un valor conocido. Mocks dinámicos para desarrollo, demostraciones y cobertura de tipo fuzz donde la variedad importa más que una respuesta fija.
Un mock dinámico también puede ser condicional, lo cual es un paso más allá de la simple generación. Un mock condicional se ramifica según la solicitud: una solicitud para /orders/404 devuelve un 404, una solicitud con un token incorrecto devuelve un 401, y todo lo demás devuelve un 200 normal. Un único endpoint mock cubre así el camino feliz y varias rutas de fallo a la vez. Esto es lo que hace que un mock sea realmente útil para las pruebas, porque puede reproducir las respuestas de error que un servidor real saludable no producirá a demanda.
Dónde encaja un mock API en el desarrollo
Un mock API es útil en tres puntos. Al principio, permite que los equipos de frontend y backend acuerden un contrato y construyan en paralelo, para que ninguno espere al otro. Durante las pruebas, aísla tu código de la inestabilidad de la red y te permite activar respuestas de error que un servidor real no producirá a demanda. Y para demostraciones y prototipos, proporciona datos controlados y predecibles sin dependencias en vivo que puedan fallar en medio de una presentación. Estos escenarios se exploran más a fondo en esta guía sobre casos de uso de mocking de API.
El riesgo recurrente es la desviación. Un mock es una instantánea de una interfaz, y las interfaces cambian. Cuando la API real añade un campo o renombra uno, un mock desconectado sigue sirviendo la forma antigua y tus pruebas pasan contra un contrato que ya no existe.
La solución es tratar el mock como derivado, no como creado manualmente. Genéralo a partir del mismo esquema que publica la API real, de modo que un cambio de contrato regenere el mock. Un mock que escribiste a mano es una copia que comienza a envejecer inmediatamente; un mock generado a partir de la especificación es siempre una instantánea actual. La diferencia no se nota el primer día, pero decide si el mock sigue siendo confiable seis meses después. Apidog funciona de esta manera: diseñas la API una vez, y el endpoint mock se genera a partir de ese diseño con datos realistas inferidos de los nombres de los campos. El mock, la documentación y las pruebas de contrato de API, todos leen de una única fuente, por lo que se mantienen sincronizados. Para ver el flujo de diseño a mock de principio a fin, Descarga Apidog.
Preguntas frecuentes
¿Qué es un mock API en términos sencillos?
Un mock API es una API falsa que imita a una real. Expone las mismas rutas y devuelve respuestas con la misma estructura, pero no hay lógica real ni base de datos detrás de ella. Las respuestas están predefinidas, lo que te permite construir y probar contra la interfaz antes de que exista el servicio real.
¿Cuál es la diferencia entre un mock y un stub?
Un stub devuelve una respuesta predefinida y nada más. Un mock, en el sentido estricto de las pruebas, también verifica la interacción, por lo que puede comprobar que fue llamado el número correcto de veces con los argumentos correctos. Un stub responde; un mock responde y observa.
¿En qué se diferencia un mock API de un servidor real?
Un mock devuelve respuestas predefinidas sin computación real, por lo que es rápido, predecible y no tiene efectos secundarios. Un servidor real ejecuta lógica real contra una base de datos real, por lo que es más lento y tiene estado, pero demuestra que el sistema funciona verdaderamente. Usa un mock para el desarrollo y el servidor real para las pruebas de contrato y de extremo a extremo.
¿Debo usar un mock estático o dinámico?
Usa un mock estático cuando necesites un valor predecible para afirmar, lo cual es adecuado para pruebas unitarias. Usa un mock dinámico cuando quieras datos realistas y variados que capturen casos límite, lo cual es adecuado para el desarrollo y las demostraciones. Muchos equipos usan ambos.
¿Cómo evito que un mock API se vuelva impreciso?
Genera el mock a partir del mismo esquema que publica la API real en lugar de escribirlo a mano. Cuando el contrato cambia, el mock se regenera. Respaldarlo con pruebas de contrato programadas contra la API real detecta cualquier desviación restante a tiempo.