Tu código depende de un servicio que no controlas. Una pasarela de pago, una API de socio, un mainframe heredado, el microservicio de otro equipo. Esa dependencia está inactiva por mantenimiento, limita la tasa de tus ejecuciones de prueba, cobra por llamada o devuelve datos inestables. Así, tu desarrollo se estanca y tu pipeline de CI se pone en rojo por razones que no tienen nada que ver con tu código.
La virtualización de servicios soluciona esto. Reemplazas la dependencia real con un sustituto que se comporta como ella, para que puedas construir y probar contra algo que controlas por completo. Esta guía explica qué es la virtualización de servicios, cómo difiere del mocking y stubbing, por qué los equipos la utilizan y qué herramientas lo hacen posible, con comandos reales para WireMock, Hoverfly, Mountebank, las opciones empresariales y el servidor de simulación de Apidog para la virtualización de contratos de API.
Qué es la virtualización de servicios
La virtualización de servicios simula el comportamiento de una dependencia que no controlas para que tu aplicación pueda comunicarse con la simulación en lugar de con la cosa real.
La palabra “comportamiento” tiene peso aquí. Un buen servicio virtual no solo devuelve una carga útil fija. Coincide con los detalles de la solicitud, devuelve diferentes respuestas para diferentes entradas, mantiene el estado entre llamadas, inyecta latencia y fallos, y habla el mismo protocolo que el sistema real. El objetivo es un sustituto lo suficientemente realista como para que tu código no pueda notar la diferencia durante el desarrollo y las pruebas.
El término “virtualización de API” significa lo mismo cuando la dependencia es una API HTTP, y “simulador de API” es la herramienta que produce el endpoint virtual. Considera ambos como sinónimos para la parte de la virtualización de servicios centrada en API.
Virtualización de servicios vs. mocking vs. stubbing
Estos tres términos se superponen, y la gente los usa de forma laxa. Aquí hay una forma práctica de separarlos.
Un stub devuelve una respuesta codificada. Ignora la solicitud y siempre responde de la misma manera. Si tu prueba llama a GET /user/42 y el stub está configurado para devolver un objeto de usuario fijo, devolverá ese mismo objeto sin importar qué ID envíes. Los stubs son la forma más simple y residen dentro de tu código de prueba.
Un mock es un stub que también verifica interacciones. Registra cómo fue llamado (qué métodos, qué argumentos, cuántas veces) para que tu prueba pueda afirmar que tu código usó la dependencia correctamente. Los mocks son una herramienta de prueba unitaria. Usualmente se ejecutan en el mismo proceso, en el mismo lenguaje que tu código. Nuestra explicación sobre stubbing de API vs mocking de API profundiza en esta distinción.
La virtualización de servicios opera a través de la red, no en tu código. Levanta un servicio en ejecución en un puerto de red real que habla un protocolo real. Tu aplicación se conecta a él de la misma manera en que se conectaría a producción, cambiando una URL base o una configuración de proxy. Un servicio virtual puede tener estado, puede coincidir con condiciones de solicitud complejas y puede simular comportamientos a nivel de protocolo como códigos de estado HTTP, encabezados, streaming y fallos de conexión.
La línea entre “mock” y “virtualización de servicios” es borrosa en el habla cotidiana. Muchos equipos llaman a un servidor mock HTTP en ejecución “un mock” incluso cuando realiza una virtualización completa. Eso está bien. La distinción que importa es: ¿estás reemplazando un objeto dentro de tu proceso (mocking/stubbing), o levantando un servicio en red al que se conecta tu aplicación (virtualización)? Consulta API mocking: todo lo que necesitas saber para el lado del mock.
Por qué los equipos usan la virtualización de servicios
Tres problemas impulsan la mayor parte de su adopción.
La dependencia no está lista. Los equipos de frontend y backend trabajan en paralelo, y el frontend necesita una API funcional antes de que el backend la envíe. Un servicio virtual construido a partir del contrato de la API permite que el frontend construya con respuestas realistas hoy. Nadie espera.
La dependencia es costosa o tiene límites de tasa. Las APIs de terceros a menudo cobran por llamada o limitan agresivamente, por lo que ejecutar un conjunto completo de pruebas contra un sandbox en vivo consume cuota y dinero. Un servicio virtual es gratuito de usar, por lo que tu CI puede ejecutar miles de escenarios al día.
La dependencia es inestable o difícil de controlar. No puedes hacer fácilmente que un proveedor de pagos real devuelva un error específico, agote el tiempo de espera o envíe una respuesta mal formada. Un servicio virtual produce cualquiera de estas situaciones bajo demanda, que es como pruebas las rutas de error que fallan en producción.
También hay un beneficio de control. Las dependencias reales tienen datos que cambian bajo tu control. Un servicio virtual te proporciona un estado fijo y conocido, por lo que tus pruebas son deterministas. Una compilación exitosa significa que tu código funciona, no que un sistema remoto se comportó bien hoy.
Cómo funciona la virtualización de servicios
La mayoría de las herramientas siguen uno de dos patrones.
Grabar y reproducir. Apuntas la herramienta al servicio real como un proxy, pasas tráfico real a través de él una vez, y captura los pares solicitud/respuesta. Más tarde, reproduce esas grabaciones en lugar de llamar al servicio real. Esto es rápido porque no escribes las respuestas a mano. El modo de captura de Hoverfly y el modo de grabación de WireMock funcionan de esta manera.
Impulsado por especificaciones. Defines el servicio virtual a partir de un contrato de API o a mano: declaras qué solicitudes coinciden con qué respuestas, añades valores dinámicos y configuras comportamientos con estado. Es más trabajo inicial, pero te da control total y funciona incluso cuando el servicio real aún no existe.
De cualquier manera, el mecanismo central es la coincidencia de solicitudes. Cuando llega una solicitud, la herramienta la compara con un conjunto de reglas (ruta, método, parámetros de consulta, encabezados, cuerpo) y devuelve la respuesta vinculada a la primera coincidencia. Las herramientas mejoradas añaden plantillas, para que una respuesta pueda reflejar partes de la solicitud o generar nuevos valores en cada llamada. Así es como un servicio virtual se siente vivo en lugar de estático.
Las herramientas
Aquí están las principales opciones, desde herramientas de código abierto centradas en HTTP hasta suites empresariales pesadas. Verifica las versiones y características actuales con la documentación de cada proyecto antes de comprometerte, ya que evolucionan rápidamente.
WireMock
WireMock es una herramienta de código abierto para mocking de API y virtualización de servicios HTTP. Se ejecuta como un proceso independiente, integrado en pruebas JVM o en un contenedor. Defines las asignaciones de stub como JSON, y WireMock compara las solicitudes entrantes con ellas. Soporta grabación y reproducción contra un servicio real, plantillas de respuesta, escenarios con estado, inyección de fallos y retrasos simulados.
Ejecuta el JAR independiente:
java -jar wiremock-standalone-3.13.2.jar --port 8080
Luego registra un stub a través de su API de administración:
curl -X POST http://localhost:8080/__admin/mappings \
-H "Content-Type: application/json" \
-d '{
"request": {
"method": "GET",
"url": "/user/42"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": 42, "name": "Ada Lovelace" }
}
}'
WireMock es más potente cuando tus dependencias son HTTP y deseas un control granular en configuraciones JVM o contenerizadas. Existe una versión comercial alojada (WireMock Cloud) si deseas una opción gestionada.
Hoverfly
Hoverfly es una herramienta de virtualización de servicios ligera y de código abierto escrita en Go. Funciona como un proxy: diriges el tráfico saliente de tu aplicación a través de Hoverfly, y este graba respuestas reales o reproduce las simuladas. Se ejecuta en varios modos, incluyendo captura, simulación, espía, modificación, síntesis y diff.
Un flujo básico de captura y luego reproducción usando su comando hoverctl:
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
La API de administración de Hoverfly se ejecuta en el puerto 8888 y su proxy en el 8500 por defecto. El modelo de proxy de grabación y reproducción lo hace adecuado cuando deseas virtualizar el tráfico existente rápidamente en lugar de escribir cada respuesta a mano. También existe un Hoverfly Cloud alojado.
Mountebank
Mountebank es una herramienta de código abierto construida alrededor de “impostores”. Un impostor es un único servicio virtual que escucha en un puerto y habla un protocolo. Más allá de HTTP y HTTPS, Mountebank también maneja TCP y SMTP, lo cual es útil cuando tu dependencia no es una API REST simple. Lo controlas completamente a través de un plano de control REST en el puerto 2525.
Instálalo e inícialo:
npm install -g mountebank
mb
Luego crea un impostor enviando un JSON al puerto de control:
curl -X POST http://localhost:2525/imposters \
-H "Content-Type: application/json" \
-d '{
"port": 4545,
"protocol": "http",
"stubs": [{
"predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
"responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
}]
}'
Los predicados deciden qué solicitud coincide; las respuestas definen lo que se devuelve. El alcance multi-protocolo de Mountebank es su diferenciador entre las opciones de código abierto.
Parasoft Virtualize y Broadcom Service Virtualization
Para grandes empresas, los pesos pesados son Parasoft Virtualize y Broadcom Service Virtualization (parte de la suite DevTest). Estas son plataformas comerciales construidas para equipos que necesitan simular muchos protocolos y formatos de mensajes más allá de HTTP, conectar servicios virtuales a fuentes de datos reales y gestionar la virtualización en muchos entornos de forma centralizada.
Parasoft Virtualize anuncia soporte para una amplia gama de protocolos estándar de la industria y formatos de mensajes, además de servicios virtuales impulsados por datos alimentados desde fuentes de datos externas. La oferta de Broadcom apunta a escenarios empresariales similares con entornos virtualizados para el desarrollo y pruebas paralelos. Ambos conllevan licencias empresariales y costos de configuración, por lo que son adecuados cuando virtualizas protocolos heredados (mainframe, MQ, mensajes de longitud fija) a escala en lugar de un puñado de endpoints REST. Si tus dependencias son APIs HTTP comunes, las herramientas de código abierto anteriores o una plataforma API te cubrirán a una fracción del costo. Confirma las listas de protocolos actuales y precios con cada proveedor.
Apidog: virtualización de servicios ligera para contratos de API
Si la dependencia que necesitas virtualizar es una API HTTP definida por un contrato, Apidog cubre esa parte sin una herramienta separada. Cuando diseñas o importas una API, Apidog levanta un servidor de simulación para ella automáticamente. Tu frontend o suite de pruebas obtiene un endpoint funcional solo a partir del esquema, antes de que exista cualquier código de backend.
Lo que lo acerca más a la virtualización que a un stub simple es que el mock de Apidog es consciente del esquema y dinámico. Su Smart Mock lee tu JSON Schema y genera respuestas que respetan cada restricción (tipos, formatos, enumeraciones, campos obligatorios). También compara nombres de campos con reglas integradas, por lo que un campo llamado email devuelve un correo electrónico válido y un campo llamado city devuelve un nombre de ciudad, en lugar de basura de marcador de posición. Para un control más preciso, los valores dinámicos basados en Faker.js generan datos realistas en cada llamada, y puedes fijar valores donde necesites determinismo.
También puedes escribir reglas de mock personalizadas que devuelvan diferentes respuestas basadas en los parámetros de la solicitud, lo cual es el comportamiento de coincidencia de solicitudes que separa la virtualización de un stub fijo. El servidor de simulación se ejecuta en la GUI o sin interfaz gráfica (headless), por lo que se adapta tanto al desarrollo local como a CI. Consulta cómo simular una API en un minuto para un tutorial.
Dónde encaja Apidog: virtualización de servicios basada en contratos de API para HTTP/REST y similares. Dónde no encaja: no es una herramienta de grabación y reproducción basada en proxy para protocolos heredados arbitrarios, y no es un generador de carga. Para esos casos, las herramientas anteriores son la elección correcta. Para una comparación más amplia herramienta por herramienta, consulta comparativa de herramientas de mocking de API online y las 10 mejores herramientas de mocking de API.
Cómo empezar
Adapta la herramienta a la dependencia, no al revés.
- Identifica el protocolo. ¿HTTP/REST simple? Casi cualquier cosa aquí funciona, y una plataforma API es la que menos fricción genera. ¿Necesitas TCP o SMTP? Mountebank. ¿Protocolos empresariales heredados a gran escala? Parasoft o Broadcom.
- Decide entre grabar o especificar. Si el servicio real existe y puedes enrutar tráfico a través de él, grabar y reproducir (Hoverfly, modo de grabación de WireMock) es lo más rápido. Si aún no existe, impulsa el servicio virtual desde el contrato de la API (Apidog, stubs de WireMock, impostores de Mountebank).
- Apuesta tu aplicación por ello. Cambia una URL base o la configuración del proxy en tu entorno de prueba o desarrollo, y mantén eso detrás de una configuración para que el cambio entre lo virtual y lo real sea una sola variable.
- Añade los casos de fallo. La recompensa es probar las rutas de error, así que añade respuestas para 4xx y 5xx, tiempos de espera y cuerpos mal formados. Esa es la parte que las dependencias reales no te permitirán ensayar.
- Ejecútalo en CI. Un servicio virtual que solo se ejecuta en tu laptop te ayuda a ti, pero no a la compilación. Ponlo en el pipeline para que "verde" signifique "verde". Si necesitas un mock que se ejecute sin interfaz gráfica (headless) en CI, consulta herramientas de mock de API headless.
Para la compensación entre dependencias virtuales y reales en general, servidor mock vs servidor real explica cuándo usar cada uno.
Preguntas Frecuentes
¿Es la virtualización de servicios lo mismo que el mocking? No exactamente. El mocking generalmente reemplaza un objeto dentro de tu proceso para pruebas unitarias y verifica cómo fue llamado. La virtualización de servicios levanta un servicio en ejecución en un puerto de red al que tu aplicación se conecta a través de un protocolo real. La gente llama a los servicios virtuales HTTP “mocks” en el uso informal, lo cual está bien, pero la distinción técnica es objeto en proceso versus servicio en red.
¿Cuándo debo usar un servicio virtual en lugar de un entorno de prueba real? Usa la virtualización cuando la dependencia real no esté disponible, tenga límites de tasa, sea costosa o difícil de controlar. Te proporciona respuestas deterministas, gratuitas y siempre disponibles, y te permite simular errores que no puedes desencadenar en el sistema real. Mantén un conjunto más pequeño de pruebas contra el servicio real para la confianza final de integración.
¿Puede un servicio virtual tener estado? Sí. Herramientas como WireMock y Mountebank soportan escenarios con estado donde la respuesta cambia basándose en solicitudes previas, por ejemplo, devolviendo un carrito vacío y luego un carrito con ítems después de un POST. Esto es importante cuando simulas flujos de trabajo en lugar de llamadas individuales.
¿Necesito una herramienta empresarial de pago? Solo si estás virtualizando muchos protocolos no-HTTP o gestionando la virtualización en una organización grande. Para APIs HTTP comunes, las herramientas de código abierto (WireMock, Hoverfly, Mountebank) o un servidor mock de plataforma API se encargan del trabajo sin necesidad de licencias empresariales.
¿Cuál es la forma más rápida de virtualizar una API HTTP a partir de su especificación? Importa la definición de la API a una herramienta que genere un mock a partir del esquema. Apidog hace esto automáticamente: importa tu especificación OpenAPI y obtendrás un servidor mock consciente del esquema con datos dinámicos realistas, sin necesidad de escribir respuestas. A partir de ahí, puedes añadir reglas personalizadas para las condiciones específicas de solicitud/respuesta que necesiten tus pruebas.