Record-and-Replay Mocking: How It Works
Record-and-Replay — Record-and-replay points a mock at a real API once, captures the traffic, then serves those captured responses offline — deterministically and without hitting the real service again.
Definition
Record-and-replay is the fastest way to get a faithful offline double of a third-party API: proxy it once, keep the bytes, replay them forever in CI.
The workflow is straightforward. You point the mock at the real API as a proxy, let real traffic flow through, and the tool stores each request-response pair. From then on, the same requests are answered from the recording, so the live dependency is never called again — which is what makes nightly CI stable even when the upstream is rate-limited or down.
The trade-off is staleness. A recording captures a moment in time, so if the real API changes, your replay quietly drifts from reality. Good practice is to re-record on a schedule or after known upstream changes, so the double stays representative without becoming a source of false confidence.
Not every tool supports it equally. WireMock and MockServer both proxy-and-record natively; no-code or spec-only tools generally don’t, because they have no proxy layer to capture through. If offline fidelity to a third party matters, proxy-and-replay support is a feature worth weighing heavily.
How it works
Record-and-replay points a mock at a real API once, lets real traffic flow through as a proxy, and stores each request-response pair. From then on, identical requests are answered from the recording, so the live dependency is never called again.
The recording captures a moment in time, which is what makes nightly CI stable even when the upstream is rate-limited or down. The mock is now an offline double that behaves like the real thing did on the day you recorded it.
A minimal example
In WireMock you start the server in proxy mode with `--proxy-all` pointed at the real host, let traffic pass, and the mappings are written to disk. Disable the proxy and the same calls now return the recorded responses. MockServer follows the same pattern: proxy to the real service, capture, then replay offline.
The stored artifacts are ordinary mapping or expectation files, so they commit to the repo like any other test fixture and run headless in CI.
When you need it
Use record-and-replay for flaky, slow, or paid third-party APIs you can’t call in CI repeatedly. Proxy once, capture, and every pipeline run is deterministic and free of rate limits — the canonical use case for stable offline doubles.
It’s also the fastest way to bootstrap a realistic mock of a service you don’t own, because the recordings reflect real wire format and real quirks you’d never think to stub by hand.
When you don’t
Don’t rely on it as a permanent source of truth. A recording drifts from reality when the upstream changes, so re-record on a schedule or after known changes, or it becomes a quiet source of false confidence.
No-code or spec-only tools generally can’t do it, because they lack a proxy layer to capture through. If offline fidelity to a third party matters, pick WireMock or MockServer rather than a GUI or spec-only mock.