In WireMock, what do startRecording() and stopRecording() do to kayak-rental traffic?

## Recording as a runtime mode, not a launch option The launcher flags turn a WireMock process into a recorder for its whole life. WireMock's `startRecording()` and `stopRecording()` do the same thing to a server that is already up, for a window you choose. That difference is what makes them the calls a test fixture actually uses: the server exists before the recording and outlives it, so one process can serve ordinary stubs, record a kayak-rental session in the middle, and go back to serving stubs afterwards. Both are static methods on WireMock's client DSL, and both have an admin-API twin, so the same session can be driven from Java, from `curl`, or from a browser. ## What starting a session does In WireMock, `startRecording("https://kayaks.riverbend.example")` does two things at once: - it arranges for the running WireMock to forward requests to that target, so `GET /fleet/boats?site=lower-weir` sent to WireMock's port reaches the real kayak-rental service and the real answer comes back to your client; - it marks the server as recording, so each of those exchanges is a candidate to become a stub mapping. The overload taking a bare URL is the short form. In WireMock, `startRecording(recordSpec()...)` is the same call with a specification object in place of the string, which is where any shaping of the capture belongs. ## What stopping a session gives you WireMock's `stopRecording()` is not a fire-and-forget teardown. It returns a WireMock `SnapshotRecordResult`, and that return value is the point: - `getStubMappings()` on WireMock's result gives you the mappings that were built, in order, as objects you can inspect, count or assert on before anything is written anywhere; - the same stubs are registered on the running WireMock, so the very next kayak-rental call is answered from the capture rather than proxied onward; - calling WireMock's `stopRecording()` when no session is open is a mistake worth guarding against rather than a no-op you can rely on. A fixture that ignores the return value throws away the only structured view of what it just captured, and is then reduced to reading files to find out. ## The admin routes behind the three calls | call | admin route | |---|---| | `startRecording(...)` | `POST /__admin/recordings/start` | | `stopRecording()` | `POST /__admin/recordings/stop` | | `getRecordingStatus()` | `GET /__admin/recordings/status` | | — (browser form only) | `GET /__admin/recorder` | WireMock's `GET /__admin/recorder` has no DSL equivalent because it is not an operation: it serves a small page with a target-URL box and start and stop buttons, driving the two POST routes for you. It is the route you use to record a kayak-rental session by hand, from a browser or a manual client, with no test code at all. ## Status, and why anyone checks it WireMock's `getRecordingStatus()` reports one of three states — `NeverStarted`, `Recording` or `Stopped` — and the reason to read it is almost always shared state. A WireMock that several suites drive, or a fixture whose teardown did not run, can already be recording when your test asks it to start. The symptom is not an exception; it is a capture that quietly contains somebody else's traffic, or a session that stops earlier than you expected. Reading the status before starting is cheap and turns a confusing capture into an explicit failure. ## What the session does not do It is worth being precise about the boundaries of these two calls: 1. **They do not decide where the mappings live.** The session hands back stubs and registers them on the server; committing them, or regenerating a committed set later, is a separate concern with separate machinery. 2. **They do not clean the capture up.** Whatever the kayak-rental service returned is what you get, credentials and timestamps included. 3. **They cannot look backwards.** Anything the client sent before WireMock's `startRecording()` was called is not part of the session, no matter how recently it happened. That third point is the one that catches people out. If you drove the client, then decided you wanted a recording, the session calls are the wrong pair of tools — WireMock's snapshot route exists precisely for that case. ## A note on the other products Mountebank arranges the same capability differently: there is no start and stop pair, and a Mountebank imposter records by carrying a `proxy` response and `recordRequests`, which stays on until the imposter is changed. Whichever product you are on, the same discipline applies afterwards: read what was captured, prune it, and only then treat it as a fixture set.