ReferenceIntermediate4-6 min reference
WireMock
WireMock is an HTTP mock server: it stands in for a real API so you can test against controlled responses — including errors and delays you can't reliably trigger on the real thing. This is a quick lookup of the stub anatomy and matchers; for full setup and code, see the Snippets library linked below.
Stub anatomy
A stub maps a request match to a response:
| Part | Holds |
|---|---|
request.method | GET / POST / … |
request.urlPath / urlPattern | exact path or regex |
request.headers / queryParameters | header/query matchers |
request.bodyPatterns | match on body (JSON path, regex) |
response.status | the status code to return |
response.jsonBody / body | the payload |
response.fixedDelayMilliseconds | simulate latency |
Request matchers
| Matcher | Matches |
|---|---|
equalTo | Exact value |
matching / doesNotMatch | Regex |
containing | Substring |
equalToJson (+ ignoreExtraElements) | JSON body |
matchingJsonPath | A JSON path expression |
absent | Header/param must NOT be present |
What it's great for
- Forcing error responses (
500,429, timeouts) the real API won't give on demand. - Latency injection to test spinners, retries, and timeouts.
- Scenarios (stateful stubs) to model a sequence: e.g.
pending→complete. - Verification: assert the system-under-test called the endpoint N times with the expected body.
Common mistakes
- Over-broad matchers (
urlPattern: .*) so the wrong stub answers. - Mocking so much that tests pass while the real integration is broken — pair with contract or E2E tests.
- Forgetting to reset stubs/scenarios between tests → order-dependent flakiness.
- Asserting only the response, never verifying the request that was sent.
// Related resources