Teardown and Reset

## A WireMock server holds four stores, not one Almost every reset mistake starts from picturing a WireMock server as one undivided bucket of state. It is four, and each reset call is named after the one it touches. - The **stub set** -- the mappings that decide which canned reply a request gets. - The **request journal** -- the record of what actually arrived, in the order it arrived. - **Scenario state** -- how far each stateful sequence has advanced. - **Global settings** -- server-wide values, read and written through `GET /__admin/settings` and `PUT /__admin/settings`. `resetRequests()` is the call named after the journal, and it is the narrowest member of the family. ## What resetRequests() does, precisely `resetRequests()` on WireMock's `WireMockServer` resets the request journal and does nothing else -- internally that is the entire implementation, a single call onto the journal with no second step. After it returns, four things are true. 1. Every stub mapping is still registered and still answering, whether it arrived in the start-up set or from a run-time `stubFor(`. 2. Every scenario is still on whatever state it had reached, so a sequence half-way through stays half-way through. 3. The global settings are unchanged, because no reset call in WireMock touches that store. 4. Only the record of received requests is gone, so anything that reads the journal now reads an empty one. That last point is the whole purpose. If you want the next `/turbines/WTG-0417/status` assertion to count from zero without disturbing the fixture that answers it, this is the call. ## Three doors onto the same operation WireMock exposes this reset three ways, and which one you have depends on how you are addressing the server. - `resetRequests()` on `WireMockServer` -- the instance method, when you hold the server object. - `WireMock.resetAllRequests()` -- the static in the client DSL, after `configureFor(`. - `DELETE /__admin/requests` -- the admin-API form, which is why it reads as a delete on the requests collection rather than as something called a reset. The awkward part is that the instance method and the static do not share a spelling. `resetRequests()` and `resetAllRequests()` are the same operation on different types, and picking the wrong one is a compile error rather than a silent behavioural bug -- which is the good outcome. ## Why the broad reset is not the safer choice There is a reflex that says a bigger reset is a more thorough reset and therefore the conservative option. On WireMock it is the reverse: a broader reset removes state that later cases were relying on, and it removes it silently. | what you actually want | the WireMock call | what it also costs you | |---|---|---| | the recorded requests gone | `resetRequests()` | nothing else changes | | stateful sequences back at the start | `resetScenarios()` | nothing else changes | | the stub set back to the start-up defaults | `resetToDefaultMappings()` | every run-time `stubFor(` registration, and the journal | | all of the above at once | `resetAll()` | the same, because it delegates to `resetToDefaultMappings()` | Read the bottom two rows together: `resetAll()` is not a fifth, stronger option. It is the third row under another name. ## Choosing on a turbine-status suite The decision rule is short: name the store you dirtied, and call the reset named after it. - A case that only sent requests dirtied the journal. `resetRequests()`. - A case that walked a stateful sequence dirtied scenario state. `resetScenarios()`. - A case that registered its own mapping dirtied the stub set, and only then is a mapping-level reset in scope at all. - A case that changed a global setting dirtied a store no reset call reaches, so it has to write the value back itself. ## Where people go wrong - Reaching for `resetAll()` because it sounds like the safe default, and taking out a shared baseline in the process. - Assuming that clearing the journal also rewinds scenario state, then being surprised that a sequence answers from its second step. - Assuming the reverse, that returning scenarios to the beginning also empties the journal. - Reading `resetRequests()` as "remove the stubs that handle requests", which is the opposite of what it does; the word *requests* refers to received requests, not to request patterns. Getting this right is not a micro-optimisation. On a server that several suites share, the difference between the journal-only call and the broad one is the difference between a clean count and a stranded fixture, and the second failure surfaces a long way from the line that caused it.