TL;DR
Los servicios de simulación (mock) de SoapUI simulan puntos finales SOAP o REST localmente, pero requieren un proceso Java en ejecución, configuración manual de despacho y no pueden compartirse en un equipo sin una máquina compartida. Smart Mock de Apidog genera respuestas de simulación a partir de su esquema de API, se ejecuta en la nube y se comparte automáticamente con su equipo.
Introducción
Los servicios de simulación (mock) resuelven un problema común en el desarrollo de API: desea probar cómo su código cliente maneja un servicio antes de que ese servicio esté listo, o desea probar casos extremos (errores, respuestas lentas) sin causarlos en un sistema real.
La función de servicio de simulación de SoapUI ha estado disponible desde las primeras versiones y funciona. Ejecuta un servidor HTTP local que responde a las solicitudes según las reglas que configure. El problema es que este proceso local crea fricción: se cierra cuando cierra SoapUI, otros miembros del equipo no pueden acceder a él sin trucos de red, y la interfaz de configuración es engorrosa.
Esta guía cubre cómo funcionan los servicios de simulación de SoapUI, cómo configurarlos, los problemas comunes que encuentran los equipos y cómo se compara el enfoque de Apidog.
Cómo funcionan los servicios de simulación de SoapUI
SoapUI crea servicios de simulación a partir de interfaces SOAP o REST existentes en su proyecto. El servicio de simulación:
- Escucha en un puerto local que usted configure (por ejemplo,
http://localhost:8088/MockService) - Intercepta las solicitudes entrantes
- Coincide la solicitud con una "respuesta de simulación" usando la lógica de despacho
- Devuelve la respuesta configurada
Para los servicios SOAP, SoapUI puede generar automáticamente respuestas de simulación a partir de su WSDL, creando respuestas de stub para cada operación. Esto es útil para simular un servicio antes de que exista o antes de que tenga acceso al punto final real.
Configuración de un servicio de simulación de SoapUI (paso a paso)
Para una interfaz SOAP
- En su proyecto SoapUI, haga clic derecho en una interfaz SOAP en el árbol del proyecto.
- Seleccione "Generar MockService."
- En el diálogo, configure:
- Nombre del servicio (por ejemplo, "OrderService Mock")
- Número de puerto (el predeterminado es 8088; cámbielo si ese puerto está en uso)
- Ruta (por ejemplo,
/orders)
- Haga clic en Aceptar. SoapUI crea un nodo MockService en el árbol de su proyecto.
- Expanda el nodo MockService. Verá una "MockOperation" para cada operación SOAP en la interfaz.
- Haga doble clic en una MockOperation para abrir el editor de respuestas simuladas.
- Edite el XML de respuesta SOAP para devolver los valores que desea simular.
- Haga clic en el botón verde de reproducción en el editor de MockService para iniciar el servidor local.
Su simulación se está ejecutando ahora en http://localhost:8088/orders. Apunte su código cliente a esta URL.
Para una interfaz REST
- Haga clic derecho en una interfaz REST o recurso en el árbol del proyecto.
- Seleccione "Agregar a MockService" o "Generar MockService".
- Configure el puerto y la ruta como se indicó anteriormente.
- Para cada recurso/método, configure el cuerpo de la respuesta simulada y el código de estado.
- Inicie el servicio de simulación.
Configuración del despacho
Por defecto, el servicio de simulación de SoapUI devuelve la primera respuesta simulada que encuentra. Si desea diferentes respuestas para diferentes entradas, configure un "script de despacho" (Groovy) o use el tipo de despacho "SEQUENCE".
Despacho de secuencia: Devuelve respuestas en un orden fijo en llamadas sucesivas. La llamada 1 obtiene la respuesta A, la llamada 2 obtiene la respuesta B.
Despacho de SCRIPT: Un script Groovy inspecciona la solicitud y devuelve un nombre de respuesta basado en la lógica.
Ejemplo de script de despacho:
def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
return "OrderFoundResponse"
} else {
return "OrderNotFoundResponse"
}
Usted crea múltiples respuestas simuladas con nombre (por ejemplo, "OrderFoundResponse", "OrderNotFoundResponse") y el script de despacho selecciona cuál devolver basándose en el contenido de la solicitud entrante.
Problemas comunes del servicio de simulación de SoapUI
Problema 1: La simulación se detiene cuando SoapUI se cierra
El servicio de simulación de SoapUI se ejecuta como parte del proceso JVM de SoapUI. Cuando cierra SoapUI, la simulación se detiene. Los compañeros de equipo que están usando la simulación la pierden.
Soluciones alternativas:
- Mantenga SoapUI abierto en una máquina o VM dedicada
- Use la opción de servidor de simulación de línea de comandos de SoapUI:
mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml - Use una máquina compartida persistente que siempre ejecute la simulación
Ninguna de estas es elegante. La opción de línea de comandos ayuda, pero aún requiere una máquina con SoapUI y Java instalados.
Problema 2: Compartir la simulación con el equipo
Una simulación en localhost:8088 solo es accesible para la persona que la ejecuta. Para que los compañeros de equipo accedan a la misma simulación, necesita acceso a la red de esa máquina (reglas de firewall, configuración de VPN) o ejecutar la simulación en un servidor compartido.
Problema 3: Los scripts de despacho fallan con XML complejo
Los scripts de despacho de SoapUI usan la coincidencia de cadenas de Groovy en el cuerpo XML sin procesar. Los sobres SOAP tienen espacios de nombres, y el mismo valor lógico puede aparecer con diferentes prefijos de espacio de nombres dependiendo del cliente. Los scripts que buscan cadenas literales como <orderId>12345</orderId> fallan cuando el prefijo difiere.
La solución requiere un análisis XML adecuado en el script de despacho utilizando la clase GroovyUtils de SoapUI, lo que aumenta la complejidad.
Problema 4: El estado no persiste entre llamadas
Los servicios de simulación de SoapUI son sin estado por defecto. Si desea simular un flujo de trabajo de crear y luego leer (POST para crear, GET para recuperar), necesita un script de despacho Groovy que almacene el estado en una variable compartida. Esto funciona, pero es frágil.
Problema 5: SSL para servicios de simulación
Configurar HTTPS para un servicio de simulación de SoapUI requiere configurar un almacén de claves, configurar los ajustes SSL de SoapUI y apuntar a los clientes al certificado correcto. Esto es considerablemente más complejo que las simulaciones solo HTTP.
Apidog Smart Mock: cómo se compara
El enfoque de simulación de Apidog parte del diseño de la API, no de un proceso en ejecución.
Cuando define un punto final de API en Apidog (método, ruta, esquema de solicitud, esquema de respuesta), Apidog genera automáticamente un punto final de simulación en la nube. No se requiere configuración.
La URL de simulación se ve así: https://{your-project}.mock.apidog.io/orders/{id}
Esta URL es:
- Siempre en ejecución (no hay un proceso local que iniciar o detener)
- Accesible para cada miembro del equipo con acceso al proyecto
- Genera respuestas a partir del esquema que definió
Cómo Apidog genera respuestas simuladas
Apidog lee su esquema de respuesta (JSON Schema o definición de respuesta OpenAPI) y genera datos falsos realistas. Un esquema que dice que orderId es una string en formato UUID devuelve un UUID aleatorio. Un esquema que dice que amount es un number entre 0 y 10000 devuelve un número en ese rango.
También puede configurar reglas de simulación personalizadas para campos específicos. Establezca orderId para que siempre devuelva "test-123" cuando necesite un valor predecible.
Puntos finales SOAP en Apidog Mock
Smart Mock de Apidog está diseñado para puntos finales REST con respuestas JSON. Para los puntos finales SOAP, la configuración de simulación es manual: usted crea una solicitud en Apidog, configura una respuesta personalizada con un sobre SOAP y usa el servidor de simulación de Apidog para devolverla.
Esto es menos automatizado que la generación de simulación basada en WSDL de SoapUI, pero funciona para equipos que necesitan una simulación SOAP simple sin ejecutar un proceso Java local.
Simulación con estado
Apidog admite scripts de respuesta personalizados para un comportamiento de simulación con estado. Puede inspeccionar el cuerpo de la solicitud en un script de simulación de JavaScript y devolver diferentes respuestas basándose en el contenido de la solicitud, de manera similar a los scripts de despacho de SoapUI pero en JavaScript.
Comparación lado a lado
| Característica | Simulación de SoapUI | Apidog Smart Mock |
|---|---|---|
| Requiere Java | Sí | No |
| Siempre activo | Solo con ejecutor de línea de comandos | Sí (nube) |
| Accesible para el equipo | Red manual | Sí, a través de URL compartida |
| Generación automática de WSDL | Sí | No |
| Basado en esquema REST | No | Sí |
| Respuestas dinámicas | Despacho Groovy | Scripts de simulación JavaScript |
| Soporte HTTPS | Configuración manual de almacén de claves | Incorporado |
| Simulación con estado | A través de variables Groovy | A través de scripts JavaScript |
| Gratuito | Sí | Sí |
Cuándo usar cada uno
Use los servicios de simulación de SoapUI cuando:
- Necesita simular un servicio SOAP basado en WSDL y desea stubs de respuesta autogenerados
- Su equipo trabaja sin conexión o detrás de estrictos controles de red
- Ya está inmerso en el ecosistema de SoapUI y no desea cambiar de herramientas
Use Apidog Smart Mock cuando:
- Su equipo simula puntos finales REST y necesita acceso compartido sin configuración de red
- Desea servidores de simulación que se mantengan en funcionamiento sin intervención manual
- Está comenzando un nuevo proyecto y definiendo el contrato de la API antes de la implementación
- Quiere evitar instalar y mantener un entorno Java para servicios de simulación
Preguntas frecuentes
¿Puedo ejecutar servicios de simulación de SoapUI sin interfaz gráfica (headlessly)?Sí. SoapUI incluye mockservicerunner.sh (Linux/macOS) y mockservicerunner.bat (Windows). Ejecútelos con la ruta del archivo del proyecto y el nombre del servicio. Aún necesita Java instalado, pero no necesita tener la GUI abierta.
¿Apidog es compatible con los servicios de simulación SOAP?Parcialmente. Puede configurar respuestas personalizadas con XML SOAP en el servidor de simulación de Apidog. No obtendrá la generación automática de respuestas stub basada en WSDL. Para equipos con interfaces SOAP bien comprendidas, la configuración manual es manejable.
¿Pueden los servicios de simulación de SoapUI simular respuestas lentas?Sí. En la configuración de la respuesta de simulación, establezca un valor de "Retraso" en milisegundos. Apidog también admite la configuración de retraso de respuesta para simular condiciones de red lentas.
¿Cuántas solicitudes simuladas puede manejar Apidog?El servidor de simulación en la nube de Apidog maneja cargas típicas de desarrollo y pruebas. Para pruebas de rendimiento de alto volumen, una herramienta de servidor de simulación dedicada puede ser más apropiada.
¿Qué sucede si dos miembros del equipo necesitan diferentes respuestas simuladas para el mismo punto final?En SoapUI, cada persona ejecuta su propia simulación local y puede configurarla de forma independiente. En Apidog, puede crear múltiples entornos o usar parámetros de consulta para seleccionar diferentes escenarios de respuesta. La función "Mock expects" de Apidog le permite hacer coincidir condiciones de solicitud específicas con respuestas específicas.
¿La simulación de Apidog requiere que la API esté completamente definida primero?Un esquema de respuesta ayuda a Apidog a generar datos realistas, pero puede crear respuestas simuladas manuales sin un esquema completo. Defina el punto final, establezca un cuerpo de respuesta personalizado y la simulación funcionará.
El servicio de simulación de SoapUI es funcional pero está vinculado a un proceso Java local. Para los equipos modernos que necesitan simulaciones persistentes y compartidas, el enfoque basado en la nube de Apidog elimina la sobrecarga de coordinación.