SoapUI Mock Service: Setup Guide and Modern Alternative

TL;DR

SoapUI mock services simulate SOAP or REST endpoints locally, but they require a running Java process, manual dispatch configuration, and cannot be shared across a team without a shared machine. Apidog’s Smart Mock generates mock responses from your API schema, runs in the cloud, and shares automatically with your team.

Introduction

Mock services solve a common problem in API development: you want to test how your client code handles a service before that service is ready, or you want to test edge cases (errors, slow responses) without causing them in a real system.

SoapUI’s mock service feature has been available since the early versions and it works. It runs a local HTTP server that responds to requests according to rules you configure. The problem is that this local process creates friction: it dies when you close SoapUI, other team members cannot access it without networking tricks, and the configuration interface is cumbersome.

This guide covers how SoapUI mock services work, how to set them up, the common problems teams hit, and how Apidog’s approach compares.

How SoapUI mock services work

SoapUI creates mock services from existing SOAP or REST interfaces in your project. The mock service:

1. Listens on a local port you configure (e.g., http://localhost:8088/MockService)
2. Intercepts incoming requests
3. Matches the request to a “mock response” using dispatch logic
4. Returns the configured response

For SOAP services, SoapUI can auto-generate mock responses from your WSDL, creating stub responses for each operation. This is useful for simulating a service before it exists or before you have access to the real endpoint.

Setting up a SoapUI mock service (step by step)

For a SOAP interface

1. In your SoapUI project, right-click on a SOAP interface in the project tree.
2. Select “Generate MockService.”
3. In the dialog, configure:

• Service name (e.g., “OrderService Mock”)
• Port number (default is 8088; change if that port is in use)
• Path (e.g., /orders)

1. Click OK. SoapUI creates a MockService node in your project tree.
2. Expand the MockService node. You will see a “MockOperation” for each SOAP operation in the interface.
3. Double-click a MockOperation to open the mock response editor.
4. Edit the SOAP response XML to return the values you want to simulate.
5. Click the green play button in the MockService editor to start the local server.

Your mock is now running at http://localhost:8088/orders. Point your client code at this URL.

For a REST interface

1. Right-click on a REST interface or resource in the project tree.
2. Select “Add to MockService” or “Generate MockService.”
3. Configure the port and path as above.
4. For each resource/method, configure the mock response body and status code.
5. Start the mock service.

Configuring dispatch

By default, SoapUI’s mock service returns the first mock response it finds. If you want different responses for different inputs, configure a “dispatch script” (Groovy) or use the “SEQUENCE” dispatch type.

Sequence dispatch: Returns responses in a fixed order on successive calls. Call 1 gets response A, call 2 gets response B.

SCRIPT dispatch: A Groovy script inspects the request and returns a response name based on logic.

Example dispatch script:

def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
  return "OrderFoundResponse"
} else {
  return "OrderNotFoundResponse"
}

You create multiple named mock responses (e.g., “OrderFoundResponse,” “OrderNotFoundResponse”) and the dispatch script selects which one to return based on the incoming request content.

Common SoapUI mock service problems

Problem 1: Mock stops when SoapUI closes

SoapUI’s mock service runs as part of the SoapUI JVM process. When you close SoapUI, the mock stops. Teammates who are using the mock lose it.

Workarounds:

• Keep SoapUI open on a dedicated machine or VM
• Use SoapUI’s command-line mock server option: mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml
• Use a persistent shared machine that always runs the mock

None of these are elegant. The command-line option helps, but it still requires a machine with SoapUI and Java installed.

Problem 2: Sharing the mock across the team

A mock on localhost:8088 is only accessible to the person running it. For teammates to access the same mock, you need network access to that machine (firewall rules, VPN setup) or to run the mock on a shared server.

Problem 3: Dispatch scripts break with complex XML

SoapUI dispatch scripts use Groovy string matching on the raw XML body. SOAP envelopes have namespaces, and the same logical value can appear with different namespace prefixes depending on the client. Scripts that search for literal strings like <orderId>12345</orderId> break when the prefix differs.

The fix requires proper XML parsing in the dispatch script using SoapUI’s GroovyUtils class, which increases complexity.

Problem 4: State does not persist between calls

SoapUI mock services are stateless by default. If you want to mock a create-then-read workflow (POST to create, GET to retrieve), you need a Groovy dispatch script that stores state in a shared variable. This works but is brittle.

Problem 5: SSL for mock services

Configuring HTTPS for a SoapUI mock service requires setting up a keystore, configuring SoapUI’s SSL settings, and pointing clients at the right certificate. This is considerably more involved than HTTP-only mocks.

Apidog Smart Mock: how it compares

Apidog’s mock approach starts from the API design, not from a running process.

When you define an API endpoint in Apidog (method, path, request schema, response schema), Apidog automatically generates a mock endpoint in the cloud. No configuration required.

The mock URL looks like: https://{your-project}.mock.apidog.io/orders/{id}

This URL is:

• Always running (no local process to start or stop)
• Accessible to every team member with access to the project
• Generating responses from the schema you defined

How Apidog generates mock responses

Apidog reads your response schema (JSON Schema or OpenAPI response definition) and generates realistic fake data. A schema that says orderId is a string in UUID format returns a random UUID. A schema that says amount is a number between 0 and 10000 returns a number in that range.

You can also configure custom mock rules for specific fields. Set orderId to always return "test-123" when you need a predictable value.

SOAP endpoints in Apidog Mock

Apidog’s Smart Mock is designed for REST endpoints with JSON responses. For SOAP endpoints, the mock setup is manual: you create a request in Apidog, configure a custom response with a SOAP envelope, and use Apidog’s mock server to return it.

This is less automated than SoapUI’s WSDL-based mock generation, but it works for teams that need a simple SOAP mock without running a local Java process.

Stateful mocking

Apidog supports custom response scripts for stateful mock behavior. You can inspect the request body in a JavaScript mock script and return different responses based on request content, similar to SoapUI’s dispatch scripts but in JavaScript.

Side-by-side comparison

When to use each

Use SoapUI mock services when:

• You need to mock a WSDL-based SOAP service and want auto-generated response stubs
• Your team works offline or behind strict network controls
• You are already deep in the SoapUI ecosystem and do not want to change tools

Use Apidog Smart Mock when:

• Your team mocks REST endpoints and needs shared access without networking setup
• You want mock servers that stay running without manual intervention
• You are starting a new project and defining the API contract before implementation
• You want to avoid installing and maintaining a Java environment for mock services

FAQ

Can I run SoapUI mock services headlessly (without the GUI)?Yes. SoapUI includes mockservicerunner.sh (Linux/macOS) and mockservicerunner.bat (Windows). Run them with the project file path and service name. You still need Java installed, but you do not need the GUI to be open.

Does Apidog support SOAP mock services?Partially. You can configure custom responses with SOAP XML in Apidog’s mock server. You do not get WSDL-based auto-generation of stub responses. For teams with well-understood SOAP interfaces, the manual setup is manageable.

Can SoapUI mock services simulate slow responses?Yes. In the mock response configuration, set a “Delay” value in milliseconds. Apidog also supports response delay configuration for simulating slow network conditions.

How many mock requests can Apidog handle?Apidog’s cloud mock server handles typical development and testing loads. For high-volume performance testing, a dedicated mock server tool may be more appropriate.

What happens if two team members need different mock responses for the same endpoint?In SoapUI, each person runs their own local mock and can configure it independently. In Apidog, you can create multiple environments or use query parameters to select different response scenarios. Apidog’s “Mock expects” feature allows you to match specific request conditions to specific responses.

Does Apidog’s mock require the API to be fully defined first?A response schema helps Apidog generate realistic data, but you can create manual mock responses without a full schema. Define the endpoint, set a custom response body, and the mock works.

SoapUI’s mock service is functional but tied to a local Java process. For modern teams that need persistent, shared mocks, Apidog’s cloud-based approach removes the coordination overhead.