Mocking for CI Pipelines: A Practical Buyer’s Guide
What actually matters when mocks run unattended
Pick by scenario
JVM / CI → WireMock
Runs as a sidecar; deterministic doubles, no flake.
OpenAPI → Prism
Mock from the spec inside the pipeline.
Decision matrix
| Feature | WireMock | Prism |
|---|---|---|
| Runs in CI | ✓ | ✓ |
| OpenAPI-native | ✗ | ✓ |
Our stance
In CI, a mock has one job: be deterministic. Proxy-and-replay tools like WireMock record once and serve the same bytes forever, which is exactly what an unattended pipeline needs.
The trap teams fall into is mocking with a tool that needs a human. A desktop GUI or a click-built environment is fine on a laptop but breaks the moment an unattended pipeline tries to start it. For CI you want something you can boot with one command or a sidecar container and then forget about.
Favor record-and-replay for third-party dependencies. Proxy the real service once, capture the traffic, and serve those exact bytes forever. The mock then reflects reality without calling it, which is what keeps nightly runs green when the upstream API is flaky or rate-limited.
Finally, make the mock part of the contract, not a separate artifact. When the mock is generated from the same spec or expectation the tests assert against, a breaking change fails loudly in CI instead of silently shipping. That is the difference between a mock that helps and one that hides risk.
When NOT to use a mock
Don’t mock when the goal is to test the real integration end-to-end. A mock proves your client handles a known double; it tells you nothing about whether the real service honors the contract. Keep at least one true integration run in the suite so the mock and reality don’t silently diverge.
Don’t mock a dependency you control and can stand up cheaply. If the real service boots in a test container in seconds, a mock adds a second source of truth for no benefit. Mock the flaky, slow, or paid third party; run the fast, local, owned service for real.
A quick tooling cheat-sheet
Record-and-replay for third parties → WireMock or MockServer, proxy once and serve offline forever. Spec-first inside the pipeline → Prism, mock from the contract. Need the mock to assert what the client sent → MockServer’s verification. Want zero servers and one laptop → Mockoon stays local, not CI.
The throughline is determinism: the CI mock’s only job is to answer the same way every run. Pick the tool that lets you boot it with one command and then forget it, and keep the real integration test as the check that the mock hasn’t drifted.