In what order would you undo a WireMock ferry fixture's catch-all stub and its --no-request-journal flag?
answer
- cheapest reversal first
- recording changes no response
- evidence before behaviour
- each red is a real gap
basics
~20 sTurn WireMock's request journal back on first. Recording changes no response, so nothing can break, and verify() plus the serve-event list immediately show what the suite really sends. Only then narrow or delete the catch-all mapping, which does change behaviour.
solid answer
~50 sUndo them in order of risk. Removing `--no-request-journal` is behaviourally free: the journal only records what WireMock already served, so no response changes and no test can turn red because of it — but `verify(...)`, `findAll(...)` and `getAllServeEvents()` start working again, which is how you learn what the ferry suite actually sends. Spend one run collecting that evidence: which paths are hit, which are typos, which endpoints have no specific mapping at all. Then attack the catch-all, which is the half that does change behaviour: constrain it to the one path prefix that needed it, or delete it and let the reds appear. Fix each red as a real gap — a missing mapping, a wrong URL in the client, a call that should not happen — rather than restoring the blanket mapping to recover green.
go deeper
Know that WireMock's journal only records traffic, so switching it back on cannot change a response, while a mapping decides what the server sends. The two carry very different risk.
Explain what re-enabling the journal buys you: verify() and the serve-event list become usable again, so you can enumerate what the suite really sends before touching a single mapping.
Walk the sequence and name the evidence at each step, and be explicit that every newly red test is a defect the catch-all was hiding rather than a regression removal introduced.
Frame it as a migration with a budget: how many reds the team can absorb per week, who owns them, and what prevents the blanket mapping returning the next time a build blocks a release.
## The two things you inherited They look like one problem and they are not. A **catch-all mapping** — in WireMock, a stub whose request pattern constrains nothing, typically `any(anyUrl())` returning a bland `200` — changes what the server *sends*. The **journal switch**, `--no-request-journal`, changes only what the server *remembers*: the disabled journal raises `RequestJournalDisabledException` from the count, the matching-request lookup, the serve-event list and the journal removals, so `verify(...)`, `findAll(...)` and `getAllServeEvents()` cannot answer. One is a behaviour change; the other is an evidence change. That asymmetry decides the order. ## Step one: turn the journal back on Recording is a side effect of serving, not part of it. WireMock matches the request, selects the mapping, writes the reply, and then — if the journal is live — stores an entry. Removing `--no-request-journal` from the CI command line therefore cannot make a passing test fail: no response changes, no mapping is selected differently, nothing the client can observe moves. What changes is that the suite regains the ability to ask questions. That is the whole reason it goes first. It is a reversible edit with no blast radius that produces exactly the evidence the expensive edit needs. Doing it in the other order — deleting the mapping while blind — gives you a red build and no way to explain it. ## Step two: run once and read what the suite actually sends With the journal live, spend one green run collecting facts rather than changing anything: - `getAllServeEvents()` gives you every request the run made, in order. - `findAll(...)` narrows that to a pattern — every call under `/v1/routes/`, say — and returns `LoggedRequest` objects you can print. - `GET /__admin/requests` does the same over HTTP when the suite runs out of process. - The interesting entries are the ones no specific mapping was ever written for: a path with a typo, a `POST /v1/bookings` that postdates the fixture, a departure lookup fired twice per test. Every one of those is a request the catch-all has been answering, and the list is your work queue — obtained before anything is broken. ## Step three: narrow, then remove, the mapping 1. Write specific mappings for the calls the evidence says are legitimate: the ferry endpoints the client genuinely uses and the fixture never covered. 2. Constrain the broad mapping rather than deleting it outright — scope it to the single path prefix that needed it, so it can no longer answer for the rest of the API. 3. Delete it, and let the run go red. 4. Confirm afterwards that no mapping left in the set can answer a request nobody wrote it for. ## Reading the reds honestly A red build at step three is not a regression you caused. It is the set of failures the catch-all was absorbing, arriving at once. Each one falls into a small number of classes: - **A missing mapping.** The client calls a real ferry endpoint nobody stubbed. Write it. - **A wrong URL in the client.** The path in the code does not match the path in the contract — this is the defect the fixture was hiding, and it is worth the whole exercise on its own. - **A call that should not happen.** A retry loop, a duplicate booking submission, a request fired on a screen that should not need it. - **A test asserting nothing real.** It passed because any `200` satisfied it. Give it an assertion about the request, now that the journal can support one. The failure mode to avoid is treating the reds as noise and restoring the blanket mapping to get back to green, which puts you where you started plus a shared belief that removal "did not work". ## What to leave behind Finish by making the state you reached observable, or it will decay. A CI step that asks the instance for a request count — WireMock reports the journal as disabled rather than returning a number when the flag is set — catches the switch coming back in a copied command line. With the journal live, a test that used to assert only on the parsed timetable can now assert that the request carried the `date` parameter it was supposed to, which is what turns the suite back into evidence rather than decoration. In Mountebank the same reversal is made one imposter at a time, since `recordRequests` is a property of the imposter rather than of the process. The sequencing generalises beyond this fixture: when a system has both a behaviour lever and an observability lever set wrongly, restore observability first, because it is the one that cannot break anything and the one that tells you what the other lever has been covering for.
- How do you keep the catch-all from being reintroduced once it is gone?Make the pressure that produced it visible instead of cheap to relieve. A build failing because a new ferry endpoint has no mapping should point straight at the missing mapping, and the shared fixture should have a named owner who reviews additions. A CI probe that asks the instance for a request count — WireMock reports the journal disabled when the flag is set — keeps the other half from creeping back in a copied command line.
- What if removing the catch-all turns fifty tests red at once?Then you have measured the size of the problem, which is worth knowing. Restore it on a branch rather than on the main line and narrow it in stages: constrain it to one path prefix, fix the reds that produces, then constrain it again. Each stage shrinks the set of requests it can answer, and the work ends with no mapping in the set able to answer everything.
It is the difference between switching the ticket-barrier logs back on and moving the barrier itself. The logs cost nothing and tell you who has been walking through; moving the barrier is the part that stops the queue.
saying these in an interview costs you the question
- Deletes the catch-all first, then reverts when the build goes red
- Assumes re-enabling the journal will change how requests are served
- Treats the newly red tests as flakiness to be quarantined
- Replaces one broad mapping with a slightly less broad one and stops
- Leaves the journal off because the fixture has always run that way