MockServer
Mock and proxy server for HTTP, HTTPS, and other protocols, with strong verification APIs.
Pricing
Free / Open source
Type
Automation
Languages
Java
// VERDICT
Reach for MockServer when you need a programmable mock/proxy server to isolate integration tests from real HTTP dependencies, especially on the JVM. Skip it when a no-code GUI mock (Mockoon) or a network-layer mock (MSW) fits better.
Best for
A standalone, JVM-friendly mock and proxy server for stubbing HTTP dependencies and verifying requests, runnable as a server, Docker image or in-process.
Avoid when
You want a no-code GUI mock, or a lightweight front-end network 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 HTTP dependencies
Setup
Maintenance
Learning
Licence
// BEST FOR
- Standing in for HTTP services so integration tests run in isolation
- Expectation-based stubbing with flexible request matching
- Verifying that the system under test made the expected requests
- Running as a standalone server, Docker container or in-process (JVM)
- Acting as a proxy to record and replay real interactions
- Simulating faults, delays and error responses for resilience tests
// AVOID WHEN
- You want a no-code GUI to design mocks (Mockoon fits)
- A lightweight front-end/network-layer mock suits you better (MSW)
- You need no running server process in tests
- A zero-config fake REST API from a file would do (JSON Server)
- Your stack is non-JVM and the Java tooling is unwelcome
- You're doing consumer/provider contract testing (Pact)
// QUICK START
docker run -d --rm -p 1080:1080 mockserver/mockserver
# then set expectations via the REST API or your JUnit test// ALTERNATIVES TO CONSIDER
| Tool | Choose it when |
|---|---|
| WireMock | You want another mature JVM stubbing server with rich matching. |
| Mockoon | You want a no-code GUI mock server. |
| MSW (Mock Service Worker) | You're mocking at the network layer for frontend/Node tests. |
// MIGRATION NOTES
WireMockMockServer
Both are JVM-friendly mock/proxy servers with overlapping capabilities. Migration means re-expressing stubs as MockServer expectations - the concepts (matchers, responses, verification) map closely. Port high-value stubs first and run both only briefly during transition.
// FEATURES
- HTTP, HTTPS, and SOCKS support
- Expectations DSL for request matching
- Verification API to assert calls happened
- Proxy and recording modes
- Java, JavaScript, and REST APIs
- Helm chart and Docker images
// PROS
- Strong verification primitives for integration tests
- Multi-language clients beyond JVM
- Easy to run as a sidecar in test environments
// CONS
- Heavier than WireMock for basic stubbing
- Documentation density can intimidate newcomers
- JSON configuration verbose for complex scenarios
// EXAMPLE QA WORKFLOW
Run MockServer as a Docker/standalone server or in-process
Define expectations (request matchers -> responses)
Point the system under test at the mock
Inject delays/faults to test resilience
Verify the expected requests were made
Run as a CI service alongside integration tests
// RELATED QA.CODES RESOURCES
Cheat sheets
Glossary
Interview