WireMock
API mocking and service virtualisation for HTTP-based services — standalone, embedded, or in Docker.
Pricing
Free / Open source
Type
Automation
Languages
Java
// VERDICT
Reach for WireMock when you need to stand in for an HTTP dependency with precise, stateful stubs and fault injection. Skip it when you're validating a real API, or a lighter front-end mock like MSW fits better.
Best for
Mocking and stubbing HTTP APIs so your tests run against a controllable fake service instead of a live dependency.
Avoid when
You want to test a real API's behaviour, or you need a lightweight in-browser mock rather than a running server.
CI/CD fit
JUnit · Maven · Gradle · Docker · GitHub Actions
Languages
Java
Team fit
Java/JVM teams · Integration test teams · Teams isolating external dependencies
Setup
Maintenance
Learning
Licence
// BEST FOR
- Standing in for HTTP services your tests depend on, so they run in isolation
- Precise request matching and stateful, scenario-based stubs
- Simulating latency, faults and error responses to test resilience
- Running as a JUnit rule/extension or as a standalone/Docker server
- Decoupling test runs from unstable or rate-limited third-party APIs
- Recording real traffic and replaying it as stubs
// AVOID WHEN
- You actually want to validate the real API's behaviour
- A lightweight in-browser/network-layer mock (MSW) suits a frontend better
- You need no server process at all in your tests
- Your stack is non-JVM and adding Java tooling is unwelcome
- Simple static responses where a tiny mock server would do
- You're doing consumer/provider contract testing (Pact fits that better)
// QUICK START
docker run -it --rm -p 8080:8080 wiremock/wiremock
# or add org.wiremock:wiremock to your JUnit test dependencies// ALTERNATIVES TO CONSIDER
| Tool | Choose it when |
|---|---|
| MockServer | You want another JVM-friendly standalone mock/proxy server. |
| Mockoon | You want a GUI-driven mock server with no code. |
| MSW (Mock Service Worker) | You're mocking at the network layer for frontend/Node tests. |
// FEATURES
- Standalone JAR, JUnit rule, or Docker image
- Stub matching by URL, headers, body, JSONPath, XPath
- Response templating with Handlebars
- Recording proxy mode for capture-and-replay
- Fault and latency injection for resilience tests
- WireMock Cloud for hosted multi-team mocking
// PROS
- De-facto standard for HTTP service mocking on the JVM
- Powerful matching and templating engine
- Mature and battle-tested at scale
// CONS
- Java-based — heavier than JS-native alternatives for frontend tests
- Configuration JSON can grow unwieldy
- Some advanced features behind WireMock Cloud paid tier
// EXAMPLE QA WORKFLOW
Define stubs in code or JSON, or record from real traffic
Add request matchers and stateful scenarios as needed
Inject latency/faults to test resilience paths
Point the system under test at the mock
Run as a JUnit extension or Dockerised service in CI
Review stubs when the upstream contract changes
// RELATED QA.CODES RESOURCES
Cheat sheets
Glossary
Interview