How would you standardise WireMock reset scope across many suites stubbing one turbine-status API?
answer
- blast radius is the actual policy
- one baseline owner, not many
- defaults are the shared contract
- narrow by default, broad by exception
- resetAll() restores, it does not empty
basics
~20 sMake the start-up mapping set the contract and forbid suite-wide stubFor() baselines, then let suites use only the narrow calls, resetRequests() and resetScenarios(). Reserve WireMock's resetAll() for the moment a suite genuinely wants the start-up set back.
solid answer
~40 sThe policy turns on one mechanic: WireMock's `resetAll()` delegates to `resetToDefaultMappings()`, so the broad reset is defined by what it **restores** -- the mappings read at start-up -- not by what it empties. That makes the start-up set the only stub state with a defined lifetime, so I would write the rule around it. The start-up set is the shared contract every suite may assume is present after any reset; a run-time `stubFor()` registration is private to the case that made it and must be treated as doomed. Day to day, suites get `resetRequests()` for a clean journal and `resetScenarios()` for stateful sequences, neither of which can damage anybody else. The broad reset becomes a reviewed exception. The cost is real: teams lose ad-hoc baselines, and the shared set grows harder to change.
go deeper
You are not setting this policy, but know the vocabulary it uses. WireMock's resetAll(), resetRequests() and resetScenarios() differ in how much state they remove, not in how thorough or careful they are.
Explain the mechanic the policy rests on: resetAll() delegates to resetToDefaultMappings(), so it reloads the start-up mappings rather than leaving WireMock empty, and the two narrow calls each reach exactly one store.
Argue the operational case. Show what a shared server looks like when one suite widens its reset, how you would detect it from which stubs survived, and what evidence you would want before changing the default.
Own the tradeoff. Making the start-up set the single baseline buys predictable resets and costs teams the freedom to stub ad hoc. Say which calls you allow by default and what a suite must show to earn the broad one.
## What the policy is actually choosing between A reset policy looks like a style question and is not. It decides how much state one suite is allowed to destroy on behalf of every suite that runs after it, and on a WireMock server the range is wide: `resetRequests()` removes the record of what arrived and nothing else, while `resetAll()` tears down the live stub set, resets the journal and reloads the start-up mappings. Both are one line at the call site. Only one of them can strand somebody else's fixture. The reflex to standardise on the broadest call comes from a reasonable instinct -- more reset means more isolation -- and it is wrong here for a specific reason. WireMock's broad reset is defined by what it *restores*, not by what it empties. `resetAll()` delegates to `resetToDefaultMappings()`, which rebuilds the stub set from the mappings the server read at start-up. A suite that registered its fixture at run time does not get it back. ## The default set as the contract That mechanic hands you the policy almost ready-made. If the start-up mapping set is the thing every reset restores, then it is the only stub state with a defined lifetime, and everything else is transient by construction. So the rule to write down is a rule about where a baseline lives. - The start-up mapping set is the **shared contract**: it is what every suite can assume is present after any reset, and changing it is a change everybody feels. - A run-time `stubFor(` registration is **private to the case that made it**, and must be treated as if the next reset will remove it, because it will. - No suite may register a baseline once for a whole class and then call the broad reset part-way through. That combination is the single failure this policy exists to prevent. - Suites that only need a clean count or a rewound sequence use `resetRequests()` and `resetScenarios()`, which cannot damage anyone. ## The same choice, in three products The vocabulary differs but the shape does not, and it is worth knowing which door each product gives you before standardising a mixed estate. | product | the broad reset | the scoped alternative | |---|---|---| | **WireMock** | `resetAll()`, which delegates to `resetToDefaultMappings()` and reloads the start-up set | `resetRequests()` for the journal, `resetScenarios()` for scenario state | | **MockServer** | `MockServerClient.reset()` | `clear(...)` with a `ClearType` of `LOG`, `EXPECTATIONS` or `ALL` | | **Mountebank** | `DELETE /imposters/:id`, which removes the imposter itself | `DELETE /imposters/:id/savedRequests`, which clears one imposter's recorded requests | The interesting difference is where the scoping lives. WireMock scopes by choosing a differently named method; MockServer scopes with an enum argument on one method; Mountebank scopes by addressing a sub-resource of a particular imposter. A policy written in WireMock's vocabulary does not port across as a sentence, only as an intent. ## Making the policy enforceable A rule nobody can check is a preference. Three things make this one checkable. 1. Put the shared baseline in the start-up set, so a suite that deletes it cannot, because the next reset puts it back. 2. Make the broad reset a reviewed exception rather than the default, and say in the review what state the suite believed it had to destroy. 3. Give suites a named helper for the narrow calls so the easy path and the correct path are the same path. ## What you accept in exchange This policy is not free and it is worth being honest about the bill. - Teams lose the freedom to stand up an ad-hoc baseline for one class and lean on it. Anything durable has to go through the start-up set, which is slower and involves other people. - The start-up set grows, and a set that everyone depends on is harder to change than one nobody does. - You gain a property that is very hard to get any other way: after any reset a suite is allowed to call, the server is in a state every other suite can also assume. That is what makes the order suites run in stop mattering. - And you should name the gap out loud, because the policy does not close it: WireMock's global settings live outside the reset family entirely, so a suite that changes one has to change it back. No reset call will do that for you, and no amount of standardising on the broad reset makes it happen.
- What breaks first when one suite widens its WireMock reset from resetRequests() to resetAll()?Every stub that was registered at run time rather than read at start-up. `resetAll()` delegates to `resetToDefaultMappings()`, so the live stub set is torn down and only the start-up mappings return. A shared turbine-status baseline set up once with `stubFor()` disappears, and the next suite sees unmatched requests instead of its fixture.
- Does a stricter reset policy also stop WireMock's global settings leaking between suites?No, and that gap is worth naming explicitly. WireMock keeps global settings in a store the reset family does not reach, so a value one suite writes through `PUT /__admin/settings` is still in force afterwards. If the policy cares about it, the setting has to be written back deliberately; no reset call, however broad, will do it.
- How would you decide whether a suite has earned an exception for the broad reset?Ask what state it believes it must destroy and why the narrow calls cannot reach it. A legitimate answer names the stub set specifically -- the suite deliberately replaced a start-up mapping and wants it back. An answer that says the broad reset feels safer is the case the policy exists to refuse.
saying these in an interview costs you the question
- Mandates resetAll() everywhere as the safe default
- Lets every suite keep its own run-time baseline
- Treats reset scope as style rather than a shared contract
- Assumes a broader reset is always the more isolating one
- Ignores that global settings survive every WireMock reset