SYSTEM Cited by 1 source
MockServer¶
MockServer (mock-server.com) is an HTTP / HTTPS mock server that stands in for an external HTTP peer in tests. Developers declare expectations (on request match → respond with these headers/body/code, or delay N ms, or drop the connection) via REST or Java client APIs. Ships as a Docker image, making it a natural Testcontainers companion.
Primary role: simulate the edge cases of HTTP peers that are hard to trigger against real services —
- HTTP codes the application rarely sees (404, 410, 418, 500, 502, 503, 504).
- Timeouts: respond with a delay exceeding the client's configured timeout.
- Protocol violations: malformed JSON, truncated responses,
incorrect
Content-Length. - Connection failures: refuse, reset, drop mid-response.
Relevance to Testcontainers ingest¶
Zalando ZMS names MockServer (alongside WireMock) as the
canonical mechanism for exercising corner cases of HTTP peer
interaction in Java integration tests. Use is idiomatic:
declare a MockServer container, point the system-under-test at
its dynamic port via @DynamicPropertySource, set up
expectations per test.
Limitation explicitly flagged: a MockServer-backed IT does not catch real-API drift on the peer. The mock reflects the engineer's understanding of the peer at IT-authoring time; the real peer may evolve. Zalando recommends pairing with concepts/contract-testing (Spring Cloud Contract) to close the gap.
Seen in¶
- sources/2021-02-24-zalando-integration-tests-with-testcontainers — named as an HTTP-peer-mocking option for Testcontainers-based ITs, with the explicit caveat that it doesn't defend against real-API drift.
Related¶
- systems/testcontainers — the container lifecycle provider.
- systems/wiremock — alternative implementation with the same role.
- concepts/contract-testing — the complement MockServer alone doesn't provide.
- patterns/real-docker-container-over-in-memory-fake — using MockServer as a real HTTP peer in a test.