DEV Community

Cover image for Virtualización de Servicios: Qué Es y Herramientas Clave
Roobia
Roobia

Posted on • Originally published at apidog.com

Virtualización de Servicios: Qué Es y Herramientas Clave

Tu código depende de un servicio que no controlas: una pasarela de pago, una API de un socio, un mainframe heredado o el microservicio de otro equipo. Si esa dependencia está en mantenimiento, aplica rate limits, cobra por llamada o devuelve datos inestables, tu desarrollo se bloquea y tu pipeline de CI falla por motivos ajenos a tu código.

Prueba Apidog hoy

La virtualización de servicios resuelve ese problema reemplazando la dependencia real por un sustituto controlado que se comporta como ella. En esta guía verás qué es, cuándo usarla, cómo se diferencia de mocks y stubs, y cómo implementarla con WireMock, Hoverfly, Mountebank, herramientas empresariales y el servidor mock de Apidog para contratos de API.

Qué es la virtualización de servicios

La virtualización de servicios consiste en simular el comportamiento de una dependencia externa para que tu aplicación se conecte a una versión controlada en lugar del sistema real.

La clave está en “comportamiento”. Un buen servicio virtual no se limita a devolver siempre el mismo JSON. Debe poder:

  • Hacer matching por método, ruta, query params, headers o body.
  • Devolver respuestas distintas según la solicitud.
  • Mantener estado entre llamadas.
  • Simular latencia, timeouts y errores.
  • Usar el mismo protocolo que la dependencia real.

En APIs HTTP, también se habla de virtualización de API o servidores mock de API. En la práctica, el objetivo es el mismo: dar a tu aplicación un endpoint funcional y predecible contra el que puedas desarrollar y probar.

Virtualización de servicios vs. mocking vs. stubbing

Los términos se solapan, pero conviene separarlos de forma práctica.

Stub

Un stub devuelve una respuesta fija. Normalmente vive dentro del código de prueba y no reproduce demasiado comportamiento.

Ejemplo: si tu test llama a GET /user/42, el stub devuelve siempre el mismo usuario, sin importar los parámetros reales.

const userService = {
  getUser: async () => ({
    id: 42,
    name: "Ada Lovelace"
  })
};
Enter fullscreen mode Exit fullscreen mode

Úsalo cuando solo necesitas aislar una unidad de código y no te importa probar la comunicación real por red.

Mock

Un mock también puede devolver datos, pero además verifica interacciones: cuántas veces fue llamado, con qué argumentos y en qué orden.

expect(paymentClient.charge).toHaveBeenCalledWith({
  amount: 1000,
  currency: "USD"
});
Enter fullscreen mode Exit fullscreen mode

Los mocks son típicos de pruebas unitarias y suelen ejecutarse en el mismo proceso que tu aplicación. Para profundizar en esta diferencia, consulta stubbing de API vs mocking de API.

Virtualización de servicios

La virtualización de servicios opera fuera de tu proceso. Levantas un servicio en un puerto real y tu aplicación se conecta a él mediante HTTP, TCP, SMTP u otro protocolo.

En lugar de cambiar una clase por un mock, cambias una configuración:

PAYMENT_API_BASE_URL=http://localhost:8080
Enter fullscreen mode Exit fullscreen mode

Esto permite probar más cerca del comportamiento real de producción: URLs, headers, códigos HTTP, errores de red, latencia y flujos con estado.

En el uso cotidiano, muchos equipos llaman “mock” a un servidor HTTP virtualizado. Está bien, pero la distinción útil es esta:

  • Mock/stub: reemplaza un objeto dentro del proceso.
  • Servicio virtual: reemplaza un sistema externo mediante red.

Para el enfoque centrado en mocks, revisa API mocking: todo lo que necesitas saber.

Por qué los equipos usan virtualización de servicios

La virtualización suele adoptarse por tres motivos.

1. La dependencia todavía no está lista

Frontend y backend pueden trabajar en paralelo. Si el contrato de la API ya existe, el frontend puede consumir un servidor virtual mientras el backend se implementa.

Flujo típico:

  1. Definir o importar el contrato OpenAPI.
  2. Generar un servidor mock desde el contrato.
  3. Configurar el frontend para usar ese endpoint.
  4. Sustituirlo por el backend real cuando esté disponible.

2. La dependencia es cara o tiene rate limits

Muchas APIs de terceros cobran por llamada o limitan el número de requests. Ejecutar todo tu test suite contra el sandbox real puede consumir cuota y dinero.

Con un servicio virtual puedes ejecutar miles de escenarios en CI sin llamar a la API externa.

3. La dependencia es inestable o difícil de controlar

No siempre puedes pedirle a una pasarela de pago real que devuelva exactamente:

  • 500 Internal Server Error
  • 429 Too Many Requests
  • Un timeout de 30 segundos
  • Un body malformado
  • Una respuesta parcial

Un servicio virtual te permite reproducir esos casos bajo demanda. Eso hace que tus pruebas de rutas de error sean repetibles.

Cómo funciona la virtualización de servicios

La mayoría de herramientas siguen uno de dos patrones.

Patrón 1: grabar y reproducir

La herramienta funciona como proxy entre tu aplicación y el servicio real.

  1. Enrutas tráfico real a través de la herramienta.
  2. La herramienta captura pares request/response.
  3. Luego reproduce esas respuestas sin llamar al servicio real.

Este enfoque es útil cuando la API ya existe y quieres crear una simulación rápido.

Herramientas como Hoverfly y WireMock soportan este flujo.

Patrón 2: definir desde especificación o reglas

Aquí defines el servicio virtual a partir de un contrato o reglas manuales.

Por ejemplo:

  • GET /users/42 devuelve 200.
  • GET /users/999 devuelve 404.
  • POST /payments devuelve 201 si el body es válido.
  • POST /payments devuelve 400 si falta un campo.

Este enfoque da más control y funciona incluso cuando el backend real todavía no existe.

El mecanismo central es el matching de solicitudes. La herramienta compara cada request entrante contra reglas como:

  • Método HTTP
  • Ruta
  • Query params
  • Headers
  • Body
  • Estado previo del escenario

Cuando encuentra una coincidencia, devuelve la respuesta configurada.

Herramientas principales

Estas son opciones habituales para virtualización de servicios, desde herramientas open source centradas en HTTP hasta plataformas empresariales.

Verifica siempre la documentación actual de cada proyecto antes de adoptarlo, porque versiones y funcionalidades cambian con frecuencia.

WireMock

WireMock es una herramienta open source para mocking de API y virtualización de servicios HTTP. Puede ejecutarse como proceso independiente, dentro de pruebas JVM o en contenedores.

Soporta:

  • Stubs definidos en JSON.
  • Grabación y reproducción.
  • Response templating.
  • Escenarios con estado.
  • Retrasos artificiales.
  • Inyección de fallos.

Ejecutar WireMock standalone 

java -jar wiremock-standalone-3.13.2.jar --port 8080
Enter fullscreen mode Exit fullscreen mode

Crear un stub por 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"
      }
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Probar el endpoint virtual 

curl http://localhost:8080/user/42
Enter fullscreen mode Exit fullscreen mode

Respuesta esperada:

{
  "id": 42,
  "name": "Ada Lovelace"
}
Enter fullscreen mode Exit fullscreen mode

WireMock encaja bien si tus dependencias son HTTP y necesitas control granular en entornos JVM, Docker o CI. También existe WireMock Cloud como opción gestionada.

Hoverfly

Hoverfly es una herramienta open source escrita en Go. Funciona principalmente como proxy: enrutas tráfico a través de Hoverfly, capturas respuestas reales y luego las reproduces.

Modos habituales:

  • capture: graba tráfico real.
  • simulate: reproduce simulaciones.
  • spy: llama al servicio real si no hay simulación.
  • modify: modifica tráfico.
  • diff: compara respuestas reales contra simuladas.

Capturar y reproducir con Hoverfly 

hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
Enter fullscreen mode Exit fullscreen mode

Por defecto:

  • Proxy: localhost:8500
  • API de administración: localhost:8888

Este modelo es útil cuando ya existe tráfico real y quieres virtualizarlo sin escribir cada respuesta a mano. También existe Hoverfly Cloud como alternativa alojada.

Mountebank

Mountebank es una herramienta open source basada en “impostores”. Un impostor es un servicio virtual que escucha en un puerto y habla un protocolo.

A diferencia de muchas herramientas centradas solo en HTTP, Mountebank también soporta protocolos como TCP y SMTP, lo que lo hace útil para dependencias que no son APIs REST simples.

Instalar y arrancar Mountebank 

npm install -g mountebank
mb
Enter fullscreen mode Exit fullscreen mode

El plano de control REST se expone en el puerto 2525.

Crear un impostor HTTP 

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,
          "headers": {
            "Content-Type": "application/json"
          },
          "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}"
        }
      }]
    }]
  }'
Enter fullscreen mode Exit fullscreen mode

Probar el impostor 

curl http://localhost:4545/user/42
Enter fullscreen mode Exit fullscreen mode

Los predicados deciden qué solicitud coincide. Las respuestas definen qué devuelve el servicio virtual. Su soporte multiprotocolo es el principal diferenciador frente a otras opciones open source.

Parasoft Virtualize y Broadcom Service Virtualization

Para organizaciones grandes, Parasoft Virtualize y Broadcom Service Virtualization son opciones comerciales orientadas a virtualización a escala.

Suelen encajar cuando necesitas:

  • Simular múltiples protocolos y formatos de mensaje.
  • Virtualizar sistemas heredados.
  • Conectar servicios virtuales a fuentes de datos externas.
  • Gestionar entornos virtualizados de forma centralizada.
  • Coordinar muchos equipos y dependencias.

Parasoft Virtualize anuncia soporte para una amplia gama de protocolos estándar de industria y servicios virtuales impulsados por datos. Broadcom Service Virtualization, parte de la suite DevTest, apunta a escenarios empresariales similares.

Estas plataformas implican licencias y configuración empresarial, por lo que tienen más sentido cuando virtualizas mainframes, MQ, mensajes de longitud fija u otros sistemas complejos a escala. Para APIs HTTP comunes, WireMock, Hoverfly, Mountebank o una plataforma API suelen ser suficientes.

Confirma siempre protocolos soportados, precios y requisitos actuales con cada proveedor.

Apidog: virtualización ligera para contratos de API

Si la dependencia que necesitas virtualizar es una API HTTP definida por contrato, Apidog puede cubrir ese caso sin una herramienta separada.

Cuando diseñas o importas una API, Apidog levanta automáticamente un servidor mock. Tu frontend o suite de pruebas puede consumir un endpoint funcional a partir del esquema, incluso antes de que exista el backend.

Este enfoque es útil cuando trabajas con:

  • APIs HTTP/REST.
  • Contratos OpenAPI.
  • Desarrollo frontend y backend en paralelo.
  • Pruebas tempranas de integración.
  • Datos de respuesta realistas generados desde el esquema.

El mock de Apidog es consciente del esquema. Smart Mock lee el JSON Schema y genera respuestas que respetan restricciones como:

  • Tipos.
  • Formatos.
  • Enumeraciones.
  • Campos obligatorios.

También usa reglas basadas en nombres de campo. Por ejemplo, un campo email devuelve un correo válido y un campo city devuelve una ciudad, en lugar de texto genérico.

Para mayor control, puedes usar valores dinámicos basados en Faker.js o fijar valores cuando necesites determinismo.

También puedes crear reglas de mock personalizadas para devolver respuestas distintas según parámetros de la solicitud. Ese matching es lo que acerca el mock a la virtualización de servicios, en lugar de un stub fijo.

El servidor mock puede ejecutarse desde la GUI o en modo headless, por lo que sirve tanto para desarrollo local como para CI. Consulta cómo simular una API en un minuto para ver el flujo básico.

Apidog encaja cuando necesitas virtualización basada en contratos para APIs HTTP. No reemplaza una herramienta proxy de grabación/reproducción para protocolos heredados arbitrarios, ni es un generador de carga. Para esos casos, usa herramientas especializadas.

Para comparar opciones, revisa la comparativa de herramientas de mocking de API online y las 10 mejores herramientas de mocking de API.

Cómo empezar

Elige la herramienta según la dependencia que quieres reemplazar.

1. Identifica el protocolo

Empieza por el protocolo, no por la herramienta.

  • HTTP/REST: WireMock, Hoverfly, Apidog o Mountebank.
  • TCP o SMTP: Mountebank.
  • Protocolos empresariales heredados a escala: Parasoft o Broadcom.
  • API definida por contrato OpenAPI: Apidog o stubs generados desde especificación.

2. Decide entre grabar o definir

Si el servicio real existe y puedes enrutar tráfico:

  • Usa grabación/reproducción.
  • Herramientas candidatas: Hoverfly o WireMock.

Si el servicio todavía no existe:

  • Define desde contrato o reglas.
  • Herramientas candidatas: Apidog, WireMock o Mountebank.

3. Cambia la configuración de tu aplicación

Evita hardcodear URLs. Usa variables de entorno:

USER_API_BASE_URL=http://localhost:8080
PAYMENT_API_BASE_URL=http://localhost:4545
Enter fullscreen mode Exit fullscreen mode

En Node.js, por ejemplo:

const userApiBaseUrl = process.env.USER_API_BASE_URL;

const response = await fetch(`${userApiBaseUrl}/user/42`);
const user = await response.json();
Enter fullscreen mode Exit fullscreen mode

Así puedes alternar entre servicio virtual, sandbox y producción con una sola variable.

4. Añade casos de éxito y de fallo

No te quedes solo con 200 OK. La mayor ventaja de virtualizar es poder probar errores difíciles de reproducir.

Cubre al menos:

  • 400 Bad Request
  • 401 Unauthorized
  • 404 Not Found
  • 429 Too Many Requests
  • 500 Internal Server Error
  • Timeouts
  • Respuestas lentas
  • Bodies incompletos o malformados

Ejemplo conceptual:

# Caso feliz
GET /payments/123 -> 200

# Pago inexistente
GET /payments/999 -> 404

# Proveedor caído
POST /payments -> 503

# Rate limit
POST /payments -> 429
Enter fullscreen mode Exit fullscreen mode

5. Ejecútalo en CI

Un servicio virtual solo en tu laptop ayuda al desarrollo local, pero no protege el pipeline.

Inclúyelo en CI para que cada ejecución tenga dependencias controladas.

Ejemplo básico con Docker Compose:

services:
  app:
    build: .
    environment:
      USER_API_BASE_URL: http://wiremock:8080
    depends_on:
      - wiremock

  wiremock:
    image: wiremock/wiremock
    ports:
      - "8080:8080"
    volumes:
      - ./wiremock:/home/wiremock
Enter fullscreen mode Exit fullscreen mode

Si necesitas mocks sin interfaz gráfica para CI, revisa herramientas de mock de API headless.

Para decidir cuándo usar un servicio virtual y cuándo validar contra el entorno real, consulta servidor mock vs servidor real.

Buenas prácticas

Mantén los contratos versionados

Guarda especificaciones, stubs y simulaciones junto al código o en un repositorio controlado.

/api-contracts
  openapi.yaml

/wiremock
  mappings/
  __files/

/mountebank
  imposters.json
Enter fullscreen mode Exit fullscreen mode

Esto permite revisar cambios de API mediante pull requests.

Separa datos deterministas y datos dinámicos

Usa datos fijos cuando la prueba necesita comparar valores exactos. Usa datos dinámicos cuando solo necesitas respetar el esquema.

Ejemplo:

  • Test de cálculo: datos fijos.
  • Test de renderizado de perfil: datos dinámicos válidos.
  • Test de paginación: dataset controlado.

No intentes simular todo

Virtualiza lo que bloquea desarrollo o vuelve inestable el CI. Mantén algunas pruebas contra el servicio real para validar integración final.

Una estrategia equilibrada:

  • Muchas pruebas contra servicios virtuales.
  • Algunas pruebas contractuales.
  • Pocas pruebas end-to-end contra entornos reales.

Simula fallos desde el inicio

Los errores no deberían añadirse al final. Incluye escenarios negativos desde la primera versión del servicio virtual.

Tu código cliente debería manejar:

if (!response.ok) {
  throw new Error(`API error: ${response.status}`);
}
Enter fullscreen mode Exit fullscreen mode

Y tus pruebas deberían verificarlo.

Preguntas frecuentes

¿La virtualización de servicios es lo mismo que mocking?

No exactamente. El mocking suele reemplazar un objeto dentro del proceso y verificar cómo fue llamado. La virtualización levanta un servicio real en red al que tu aplicación se conecta mediante un protocolo.

En APIs HTTP, es común llamar “mock” a un servicio virtual, pero técnicamente la diferencia es objeto en proceso vs. servicio en red.

¿Cuándo debería usar un servicio virtual en lugar de un entorno real?

Úsalo cuando la dependencia real:

  • No está disponible.
  • Tiene rate limits.
  • Cobra por llamada.
  • Es inestable.
  • Es difícil de configurar.
  • No permite reproducir errores concretos.

Mantén pruebas más pequeñas contra el entorno real para validar integración final.

¿Puede un servicio virtual tener estado?

Sí. Herramientas como WireMock y Mountebank soportan escenarios con estado.

Por ejemplo:

  1. GET /cart devuelve carrito vacío.
  2. POST /cart/items añade un ítem.
  3. GET /cart devuelve el carrito con ítems.

Esto es importante cuando pruebas flujos, no solo llamadas aisladas.

¿Necesito una herramienta empresarial de pago?

Solo si necesitas virtualizar muchos protocolos no HTTP, sistemas heredados o administrar virtualización a escala organizacional.

Para APIs HTTP comunes, normalmente bastan herramientas open source como WireMock, Hoverfly o Mountebank, o un servidor mock integrado en una plataforma API.

¿Cuál es la forma más rápida de virtualizar una API HTTP desde su especificación?

Importa la definición de la API en una herramienta que genere mocks desde el esquema.

Con Apidog, puedes importar tu especificación OpenAPI y obtener un servidor mock consciente del esquema con datos dinámicos realistas. Después puedes añadir reglas personalizadas para cubrir condiciones específicas de request/response.

Top comments (0)