Mocking / service virtualization tools
Mocking and service virtualization tools let you stand in for an API, service, or third-party system your tests depend on — so you can test against something fast, controllable, and always available, instead of a real dependency that's slow, flaky, or hard to push into the states you need.
// WHAT THEY ARE
These tools return predefined or generated responses in place of a real service. Your application makes its normal calls; the tool intercepts them and answers — at the network layer, via a proxy, or through a local server — without the real backend involved.
The terms get used loosely, so it's worth being precise. A stub returns canned responses to make a test pass — the simplest form. A mock also returns responses but additionally lets you verify the interaction (was this endpoint called, with what?). Service virtualization is the broadest: a complete, running stand-in that mimics a real service's behavior, state, and data — used to simulate an entire dependency or environment, not a single call. In practice the tools below span this range, and most teams reach for them to do one of three things: develop a front-end before its API exists, test edge cases a real API won't easily produce (timeouts, 500s, malformed data), or remove a slow/unreliable third party from the test loop.
Key capabilities to know: request matching (by method, path, headers, query), static vs dynamic responses (templated from the request), behavior simulation (latency, faults, throttling), and record-and-replay (capture real traffic, then play it back offline).
// WHEN YOU NEED THEM
Reach for a mock when the real dependency is in your way: it doesn't exist yet, it's slow or rate-limited, it costs money per call, it's a third party you can't control, or you can't easily make it return the error and edge-case responses you need to test. A mock is faster, free, and fully under your control — you can force a 500 or a 30-second delay on demand, which a shared sandbox usually won't let you do.
// The signals
- A front-end blocked waiting on a back-end
- Flaky tests caused by an unstable downstream service
- Negative / edge-case paths you can't trigger against the real API
- A third-party integration (payments, email, geocoding) you don't want in your test loop
// COMPARISON
| Tool | Scope | Runs as | Best for |
|---|---|---|---|
| MSW | HTTP interception (service worker / Node) | In-process (JS/TS) | Front-end & component tests against simulated APIs |
| WireMock | HTTP mocking → service virtualization | Java server / standalone | The mature, powerful default; stateful, fault injection |
| Mockoon | HTTP mocking | Desktop GUI + CLI | Fastest local mock with no code |
| Mountebank | Multi-protocol (HTTP, TCP, SMTP…) | Standalone server | Non-HTTP protocols, over-the-wire stubs |
| Hoverfly | Service virtualization | Proxy | Record-and-replay of real traffic |
// OPEN SOURCE VS PAID
This category is open-source-rich. MSW, WireMock (OSS), Mockoon, Mountebank, Hoverfly, MockServer, Prism, JSON Server are all free and cover the great majority of real needs — the budget “holy trinity” for breadth is WireMock (HTTP), Mountebank (TCP/other protocols), and Mockoon (GUI). Paid tiers appear when you need collaboration, hosting, and management on top: WireMock Cloud adds team features, REST/GraphQL/gRPC, and version-controlled mocks; heavyweight enterprise service virtualization (Parasoft, Broadcom/CA, Tricentis) exists for mainframes, SOAP/MQ, and complex stateful simulation that the open-source tools don't reach. For most teams — and any learner — the open-source tools are the answer; start with MSW if you're front-end, WireMock or Mockoon if you're testing APIs.
// HOW TO CHOOSE
- 01Front-end or back-end? Testing a React/Vue/Angular app against a simulated API → MSW, which intercepts in the browser/Node without a separate server. Testing back-end services or running mocks in CI as a real endpoint → WireMock/MockServer/Mockoon.
- 02Code or GUI? Want mocks as code, versioned alongside tests → MSW, WireMock, MockServer. Want a fast visual mock with no setup → Mockoon's desktop app.
- 03How realistic does it need to be? A canned “200 OK” to unblock a button → Mockoon. Stateful flows, latency/fault injection, simulating a whole dependency → WireMock or a service-virtualization tool.
- 04HTTP only? If you need TCP, SMTP, or other protocols, most tools are HTTP-only — Mountebank handles the rest.
- 05Do you have real traffic to capture? Record-and-replay (Hoverfly) is the quickest way to virtualize an existing service you can observe but can't control.
// COMMON MISTAKES
- Mocking so much that tests stop testing reality. A mock encodes your assumption of how the real service behaves. If the real API changes and your mock doesn't, your tests stay green while production breaks. Pair mocks with some real integration or contract testing.
- Letting mocks drift from the real contract. Hand-written mock responses rot as the API evolves. Where you can, generate or validate mocks from the real schema (OpenAPI) so they track reality.
- Using mocks where a real integration test is what you actually need. Mocks answer "does my code handle this response?" — not "do these two services actually work together?" Don't mock away the integration you're supposed to be verifying.
- Over-engineering the mock. Elaborate stateful mock logic becomes its own thing to maintain and debug. Mock the minimum your test needs.
- Forgetting to test the unhappy paths the mock makes easy. The whole advantage of a mock is forcing 500s, timeouts, and malformed payloads — teams set up mocks and then only test the happy path anyway.