In WireMock, why do stubs registered with stubFor() vanish after resetAll() while start-up mappings return?

seniorshould knowfreq 58%

answer

not a clear-everything switch
delegation, not a separate operation
default means loaded at start-up
run-time additions are not defaults
resetAll() calls resetToDefaultMappings()

basics

~20 s

WireMock's resetAll() delegates to resetToDefaultMappings(), which empties the live stub set and the request journal, then reloads only the mappings the server read at start-up. A stub added later with stubFor() was never a default, so it is gone.

solid answer

~50 s

In WireMock, resetAll() is not a clear-everything switch: on WireMockServer it delegates straight to resetToDefaultMappings(). That call does three things in order -- it drops every stub mapping currently held in memory, it resets the request journal, and it reloads the default mappings, meaning the ones the server read when it started. The word default is the whole trap. A stub you registered later with stubFor(), such as a suite-wide turbine-status baseline set up once for a whole test class, is a run-time addition rather than a default, so the reload does not bring it back. Mappings that were present at start-up do come back, which is exactly why half your stub set survives and half does not. If you only wanted an empty journal, call resetRequests(); if you only wanted stateful sequences back at the beginning, call resetScenarios().

In WireMock, `resetAll()` is not a clear-everything switch: on `WireMockServer` it delegates straight to `resetToDefaultMappings()`. That call does three things in order -- it drops every stub mapping currently held in memory, it resets the request journal, and it reloads the **default** mappings, meaning the ones the server read when it started. The word *default* is the whole trap. A stub you registered later with `stubFor()`, such as a suite-wide turbine-status baseline set up once for a whole test class, is a run-time addition rather than a default, so the reload does not bring it back. Mappings that were present at start-up do come back, which is exactly why half your stub set survives and half does not. If you only wanted an empty journal, call `resetRequests()`; if you only wanted stateful sequences back at the beginning, call `resetScenarios()`.

code

java · 14 lines

java

import static com.github.tomakehurst.wiremock.client.WireMock.*;

configureFor("localhost", 8080);

// Registered at run time, so it is NOT a default mapping.
stubFor(get(urlPathEqualTo("/turbines/WTG-0417/status"))
    .willReturn(aResponse()
        .withStatus(200)
        .withHeader("Content-Type", "application/json")
        .withBody("{\"turbineId\":\"WTG-0417\",\"state\":\"PRODUCING\",\"outputKw\":3120}")));

reset();   // WireMock.reset() -> POST /__admin/reset -> resetToDefaultMappings()

// The stub above is gone. Only the mappings loaded at start-up came back.

go deeper

for a junior

Be ready to say what WireMock's resetAll() removes from a running server: every stub registered at run time, plus the whole request journal. Know that it is the broadest call in the reset family.

for a middle

Explain the delegation. WireMock's resetAll() calls resetToDefaultMappings(), which clears the stub set, resets the journal, then reloads the start-up mappings. Say why that reload makes the word default the operative one.

for a senior

Diagnose the real failure: a suite-wide stubFor() baseline is a run-time addition, so a mid-suite resetAll() strands every later case. Show how you would spot it from which stubs survived and which narrower call you would substitute.

for a principal

Own the rule about where a shared baseline lives. Decide whether teams may register suite-wide stubs at run time at all, and what you accept in exchange for making the start-up set the only thing a reset restores.

The delegation nobody expects

WireMock's resetAll() reads like the nuclear option and is not one. On WireMockServer it is a single delegation to resetToDefaultMappings(), so the two names are two doors onto one operation rather than a broad reset and a narrow one. Over WireMock's admin API the same pair appears as POST /__admin/reset and POST /__admin/mappings/reset, and from the static client DSL as WireMock.reset() and WireMock.resetToDefault(). Whichever spelling you use, you get the same three steps.

The stub set the server is currently holding is cleared, so no mapping registered at run time survives.
The request journal is reset, so nothing the server recorded before the call is still there.
The default mappings are reloaded -- the stub definitions the server read when it started.

Step three is the one that surprises people. resetAll() does not leave a WireMock server empty. It leaves the server in the state it was in the moment it finished starting, which for a server that was given a mapping set at start-up means a server that still answers turbine-status calls.

Default versus run-time, and why your baseline sits on the wrong side

WireMock's reset behaviour follows a split in the stub set that nothing in the API name hints at.

Defaults are the mappings the server read at start-up. Step three restores them, every time, in exactly the form they had then.
Run-time additions are everything registered afterwards through stubFor(. Step one destroys them and no later step brings them back.

A turbine-status suite usually has both populations. A GET /turbines/{turbineId}/status mapping that ships with the project is a default. A suite-wide baseline someone registered once with stubFor( -- the /farms/northwick-shoal/turbines roster that every case in the class leans on -- is a run-time addition. Call resetAll() part-way through that class and the roster is gone while the per-turbine mapping is still answering, which is why the failure reads as arbitrary: some requests keep working and some suddenly do not.

Reading the symptom backwards

The characteristic bug report is "a stub that was definitely registered stopped matching, and only for the cases after a certain point". The shape of what broke tells you which call ran.

If every stub vanished, the server had no defaults to reload, so step three had nothing to do.
If some stubs vanished, the survivors were defaults and the casualties were run-time additions. That is the fingerprint of resetAll() or resetToDefaultMappings().
If nothing vanished but a request count came out wrong, only the journal was touched, which is resetRequests() and not this pair.
If a stateful sequence answered from the wrong step, look at scenario state rather than at either.

WireMock's reset family, by the store it touches

WireMock call	stub set	request journal	scenario state
`resetAll()`	cleared, then the start-up defaults reloaded	cleared	rebuilt with the stub set
`resetToDefaultMappings()`	the same operation; `resetAll()` delegates to it	cleared	rebuilt with the stub set
`resetMappings()`	cleared, with nothing reloaded	untouched	--
`resetRequests()`	untouched	cleared	untouched
`resetScenarios()`	untouched	untouched	back to the initial state

In MockServer the same line is drawn with an argument rather than a method name: MockServerClient.clear(...) takes a ClearType of LOG, EXPECTATIONS or ALL, naming the store at the call site.

Three ways to fix it, and what each costs

Move the baseline into the start-up set. It becomes a default, resetAll() restores it, and the broad reset stops being dangerous. This is the strongest fix and the most expensive one, because the baseline stops being something a single test class owns and changes to it affect everybody using that server.
Register the baseline per case instead of once. Obviously correct and cheap to reason about; it costs whatever the registration costs, multiplied by the number of cases.
Stop calling the broad reset. If the suite only wanted an empty journal, resetRequests() is the call; if it only wanted stateful sequences back at the beginning, resetScenarios() is; and removeStub( takes out a single mapping when that is genuinely all that is dirty.

What survives a reset regardless

One store sits outside the whole family. WireMock keeps its global settings separately from the stub set and the journal, and no member of the reset family touches that store, so a value written through PUT /__admin/settings is still in force after resetAll() returns. Nothing puts it back except writing it back. The same is true of everything outside the server's memory: the process, its listening port and the files on disk are unaffected, because a reset is an operation on in-memory state and not a restart. Knowing which of those two categories a piece of state falls into is most of what "what survives a test" means on a shared WireMock server.

## The delegation nobody expects WireMock's `resetAll()` reads like the nuclear option and is not one. On `WireMockServer` it is a single delegation to `resetToDefaultMappings()`, so the two names are two doors onto one operation rather than a broad reset and a narrow one. Over WireMock's admin API the same pair appears as `POST /__admin/reset` and `POST /__admin/mappings/reset`, and from the static client DSL as `WireMock.reset()` and `WireMock.resetToDefault()`. Whichever spelling you use, you get the same three steps. 1. The stub set the server is currently holding is cleared, so no mapping registered at run time survives. 2. The request journal is reset, so nothing the server recorded before the call is still there. 3. The **default** mappings are reloaded -- the stub definitions the server read when it started. Step three is the one that surprises people. `resetAll()` does not leave a WireMock server empty. It leaves the server in the state it was in the moment it finished starting, which for a server that was given a mapping set at start-up means a server that still answers turbine-status calls. ## Default versus run-time, and why your baseline sits on the wrong side WireMock's reset behaviour follows a split in the stub set that nothing in the API name hints at. - **Defaults** are the mappings the server read at start-up. Step three restores them, every time, in exactly the form they had then. - **Run-time additions** are everything registered afterwards through `stubFor(`. Step one destroys them and no later step brings them back. A turbine-status suite usually has both populations. A `GET /turbines/{turbineId}/status` mapping that ships with the project is a default. A suite-wide baseline someone registered once with `stubFor(` -- the `/farms/northwick-shoal/turbines` roster that every case in the class leans on -- is a run-time addition. Call `resetAll()` part-way through that class and the roster is gone while the per-turbine mapping is still answering, which is why the failure reads as arbitrary: some requests keep working and some suddenly do not. ## Reading the symptom backwards The characteristic bug report is "a stub that was definitely registered stopped matching, and only for the cases after a certain point". The shape of what broke tells you which call ran. - If **every** stub vanished, the server had no defaults to reload, so step three had nothing to do. - If **some** stubs vanished, the survivors were defaults and the casualties were run-time additions. That is the fingerprint of `resetAll()` or `resetToDefaultMappings()`. - If **nothing** vanished but a request count came out wrong, only the journal was touched, which is `resetRequests()` and not this pair. - If a stateful sequence answered from the wrong step, look at scenario state rather than at either. ## WireMock's reset family, by the store it touches | WireMock call | stub set | request journal | scenario state | |---|---|---|---| | `resetAll()` | cleared, then the start-up defaults reloaded | cleared | rebuilt with the stub set | | `resetToDefaultMappings()` | the same operation; `resetAll()` delegates to it | cleared | rebuilt with the stub set | | `resetMappings()` | cleared, with nothing reloaded | untouched | -- | | `resetRequests()` | untouched | cleared | untouched | | `resetScenarios()` | untouched | untouched | back to the initial state | In MockServer the same line is drawn with an argument rather than a method name: `MockServerClient.clear(...)` takes a `ClearType` of `LOG`, `EXPECTATIONS` or `ALL`, naming the store at the call site. ## Three ways to fix it, and what each costs - **Move the baseline into the start-up set.** It becomes a default, `resetAll()` restores it, and the broad reset stops being dangerous. This is the strongest fix and the most expensive one, because the baseline stops being something a single test class owns and changes to it affect everybody using that server. - **Register the baseline per case instead of once.** Obviously correct and cheap to reason about; it costs whatever the registration costs, multiplied by the number of cases. - **Stop calling the broad reset.** If the suite only wanted an empty journal, `resetRequests()` is the call; if it only wanted stateful sequences back at the beginning, `resetScenarios()` is; and `removeStub(` takes out a single mapping when that is genuinely all that is dirty. ## What survives a reset regardless One store sits outside the whole family. WireMock keeps its global settings separately from the stub set and the journal, and no member of the reset family touches that store, so a value written through `PUT /__admin/settings` is still in force after `resetAll()` returns. Nothing puts it back except writing it back. The same is true of everything outside the server's memory: the process, its listening port and the files on disk are unaffected, because a reset is an operation on in-memory state and not a restart. Knowing which of those two categories a piece of state falls into is most of what "what survives a test" means on a shared WireMock server.

Does WireMock's resetAll() also clear the global settings written through PUT /__admin/settings?
No. WireMock keeps global settings in a store separate from the stub set and the request journal, and no member of the reset family touches it. A value written through `PUT /__admin/settings` is still in force after `resetAll()` returns, so a setting one case changes stays changed for the next one unless something writes it back explicitly.
If resetAll() just delegates, why does WireMock expose both names at all?
They are two entry points that share one implementation. `resetAll()` is reached through `POST /__admin/reset` and `resetToDefaultMappings()` through `POST /__admin/mappings/reset`, and both land on the same code. Treat them as one operation with two doors rather than as a broad reset and a narrow one, and reach for `resetRequests()` or `resetScenarios()` when you actually want less.
How would you prove that resetAll() is what stranded a suite rather than a matching bug?
Look at which stubs survived. If the casualties are exactly the ones registered at run time and every start-up mapping still answers, the split is the reset's, because a matching bug has no reason to respect that boundary. A matching failure also leaves the mapping registered, so it is still listed on the server.

saying these in an interview costs you the question

Says resetAll() leaves the WireMock server completely empty
Thinks resetToDefaultMappings() is the gentler of the two calls
Believes stubFor() registrations are reloaded after a reset
Assumes resetAll() also wipes WireMock's global settings
Calls resetAll() when only the request journal needed clearing

In WireMock, why do stubs registered with stubFor() vanish after resetAll() while start-up mappings return?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The delegation nobody expects

Default versus run-time, and why your baseline sits on the wrong side

Reading the symptom backwards

WireMock's reset family, by the store it touches

Three ways to fix it, and what each costs

What survives a reset regardless

▾common follow-ups3 questions

▾red flags5 flags

The delegation nobody expects

Default versus run-time, and why your baseline sits on the wrong side

Reading the symptom backwards

WireMock's reset family, by the store it touches

Three ways to fix it, and what each costs

What survives a reset regardless

answer

go deeper