WireMock vs MockServer vs proxymock for API testing

Choose WireMock for HTTP response stubs and tests that need precise fault scenarios. Choose MockServer for HTTP expectations, proxying, and request verification. Choose proxymock when you want dependency mocks built from recorded traffic and a replay baseline for code changes. The right choice depends on what your test needs to prove.

All three can help isolate an application from dependencies. A useful comparison starts with the request you need to simulate and the evidence you want back. It doesn’t start with a claim that every manually written mock is wrong or that a recording can never become stale.

WireMock vs MockServer vs proxymock at a glance

Test requirement	WireMock	MockServer	proxymock
Define an HTTP response	Request matching and response stubbing	Request expectations and response actions	Recorded responses; inspect and edit the traffic files
Check a required HTTP interaction	Request verification	Request verification, including sequences	Inspect captured traffic and replay results
Build fixtures from a working dependency	Record and playback	Proxy and record	Record application and dependency traffic
Test a precise synthetic HTTP failure	Fault simulation and delays	Configured errors and delays	Edit or transform the recorded test data as appropriate
Check changed application responses	Add assertions in your test suite	Add assertions in your test suite	Replay captured inbound requests against the changed app
Protocol focus	HTTP; extensions add capabilities such as gRPC	HTTP and HTTPS expectations	HTTP, gRPC, Postgres, MySQL and Redis; setup varies by client
Java test integration	JUnit Jupiter extension	Java client and JUnit integration	Record and mock around the application process
CI use	Start the stub server and run assertions	Start the expectation server and run assertions	Start dependency mocks and replay the saved baseline
Fixture maintenance	Review mappings when contracts change	Review expectations when contracts change	Review or re-record traffic when contracts change
Local cost	Open-source server	Open-source server	Local record, mock and replay are free
Hosted offering	WireMock Cloud has separate plans	Operate the server in your own environment	Speedscale Cloud has separate plans

This table compares workflows, rather than claiming one tool replaces every test. Check each tool’s current documentation for protocol support and deployment options. WireMock extensions, hosted products, and an OSS HTTP server aren’t interchangeable capability lists.

WireMock: controlled HTTP responses

With WireMock, define the request you expect and the response the mock should return. A mapping for a payment endpoint can match a method and path, return a JSON body, and set an HTTP status.

That fits a test where you need one specific condition: a declined payment, a malformed body, or a response that arrives too late. Keep the mapping near the test so the expected behavior is easy to review. Use request verification when the outgoing request itself is part of the contract.

WireMock also supports record and playback. A fixture can come from an observed response as well as a hand-authored mapping. Either source needs maintenance when the real dependency changes.

For Java projects, follow the JUnit Jupiter extension documentation for lifecycle management and a dynamic test port. Configure your client to use that port. Starting a mock server without pointing the application at it doesn’t isolate the dependency.

MockServer: expectations and verification

MockServer expectations pair request matching with an action, such as returning a response or forwarding a request. MockServer can also record requests and verify that an expected interaction occurred.

Use that verification for a business requirement. For example, an order should send the correct payment amount, and a declined payment should avoid triggering fulfillment. Asserting every incidental request in a long workflow can make a test sensitive to harmless refactoring.

MockServer’s proxy behavior is useful when you need to inspect requests while introducing mocks incrementally. Keep the forwarding rules explicit so you know which requests still reach real dependencies. A test with one mocked payment response and a live inventory call measures a different system from a fully isolated run.

Choose between WireMock and MockServer based on the matching, lifecycle, and verification behavior your existing test suite needs. Prototype one representative success path and one failure path before replacing a working suite.

proxymock: recorded dependency behavior and replay

With proxymock, record traffic while exercising a working application. The recording contains requests and responses that you can inspect as RRPair Markdown files. Use that recording to supply dependency responses during a later run.

The product supports protocol-aware traffic workflows for HTTP, gRPC, Postgres, MySQL, and Redis. Follow the protocol-specific setup in the docs; a JVM wrapper alone doesn’t guarantee capture of every client or protocol. Some clients need explicit proxy or port-mapping configuration.

Recorded traffic can also become a regression baseline. Replay the saved inbound requests against the changed application, supply the captured downstream responses, and inspect differences in the application’s output. This is useful when an AI coding agent modifies a handler and the reviewer needs evidence beyond the agent’s description of the change.

Start with the runnable traffic-replay walkthrough. It uses a local Go app, but the same baseline requirement applies to a Java service: record the behavior you want to preserve before changing the code.

What recorded mocks still need from you

A recording covers what happened during capture. It doesn’t automatically include every decline reason, malformed request, or timeout the application could encounter. Keep targeted tests for those conditions and add traffic samples when you discover missing cases.

Sensitive data requires deliberate handling. Inspect tokens and personal data before sharing a recording, and apply the relevant redaction settings. A recorded response also becomes stale if a dependency changes its contract; re-record or update the fixture after reviewing the change.

Choose unmatched-request behavior explicitly. proxymock can pass unmatched calls through to the real dependency by default. Use its documented --no-passthrough option when a test must not contact that dependency. A passing test that silently reached the live service isn’t proof that your mocks cover the workflow.

Pricing and operating costs

The open-source WireMock server uses the Apache 2.0 license. WireMock Cloud is a separate hosted product with free and paid plans. Check its current quotas and pricing rather than treating the open-source server and hosted service as the same purchase.

MockServer is open source. Include the cost of running it, updating fixtures, and maintaining its test integration when comparing it with a hosted service.

proxymock’s local CLI supports recording, mocking and replay for free. Speedscale Cloud pricing covers the separate cloud product. Choose based on the environment and workflow you need, then compare both subscription costs and the work required to maintain the tests.

Use both when the tests ask different questions

Keep an existing WireMock or MockServer test that checks a carefully chosen failure. Add recorded dependency mocks for integration flows whose payloads are cumbersome to invent. Add replay when you need to compare the running application’s response with a saved baseline.

For a Spring Boot change, that might mean retaining unit tests for the decision logic and an HTTP stub for a payment timeout. A separate replay run can check captured order flows after the implementation changes. The overlap is useful if each test has a clear purpose.

Compare the tools against the same representative workflow. Check how much setup it takes, whether unexpected requests are visible, and whether the result explains a failure. For the Speedscale workflow, try proxymock locally or follow the Spring Boot API testing guide.

Frequently asked questions

What is the difference between WireMock and MockServer?

Both support HTTP request matching, configured responses, and request verification. Compare their APIs and lifecycle integration against the expectations your tests need.

Can WireMock record real traffic?

Yes. WireMock supports record and playback. Captured fixtures still need review and updates when the real dependency contract changes.

When should I use proxymock instead of an HTTP stub server?

Use proxymock when you need recorded dependency responses or want to replay inbound traffic against a code change. Follow the setup requirements for each protocol and client.

Can I migrate from WireMock to proxymock?

Migrate incrementally: keep targeted WireMock tests and record one representative integration flow with proxymock. Compare the results before expanding coverage. A recording is not a one-to-one translation of WireMock matchers and verification assertions.

Does proxymock work with Spring Boot?

Yes. Follow the Java and protocol-specific setup instructions, including any client proxy or port-mapping configuration. Capture a representative flow and confirm its downstream calls appear in the recording before relying on the mocks.

How do I handle sensitive data in recorded traffic?

Configure redaction rules, inspect tokens and personal data, and review recordings before sharing them. A traffic recording does not by itself establish privacy or compliance.

How do Testcontainers and API mocks work together?

Testcontainers starts real dependencies in containers. API mocks supply controlled dependency responses. Use a real database container for database behavior and an HTTP mock for a payment timeout when those are the requirements you need to test.