In WireMock, how does resetScenarios() differ from resetRequests() on a turbine-status stub server?

middleshould knowfreq 54%

answer

two stores, two calls
counting versus position in a sequence
neither call deletes a mapping
journal reset leaves scenarios mid-sequence
scenarios return to the string Started

basics

~20 s

WireMock's resetScenarios() returns every scenario to its initial state and touches nothing else. resetRequests() empties the request journal and touches nothing else. Neither call removes a stub mapping, and the two stores are fully independent of each other.

solid answer

~40 s

They reach two different stores. In WireMock, resetRequests() resets the request journal -- the record of what the server actually received -- and stops there. resetScenarios() returns every scenario to its initial state, the string "Started", and stops there. Neither one removes a stub mapping, which is what makes them the safe pair to use on a server other suites share. The practical consequence is that they are not substitutes: empty the journal and a stateful turbine-status sequence carries on from whatever step it had reached, so the next case gets the reply meant for the previous one; rewind the scenarios and the counts still include everything recorded before. From the static client DSL the same two operations are WireMock.resetAllRequests() and WireMock.resetAllScenarios(), and resetScenario( rewinds a single named sequence.

They reach two different stores. In WireMock, `resetRequests()` resets the request journal -- the record of what the server actually received -- and stops there. `resetScenarios()` returns every scenario to its initial state, the string `"Started"`, and stops there. Neither one removes a stub mapping, which is what makes them the safe pair to use on a server other suites share. The practical consequence is that they are not substitutes: empty the journal and a stateful turbine-status sequence carries on from whatever step it had reached, so the next case gets the reply meant for the previous one; rewind the scenarios and the counts still include everything recorded before. From the static client DSL the same two operations are `WireMock.resetAllRequests()` and `WireMock.resetAllScenarios()`, and `resetScenario(` rewinds a single named sequence.

code

java · 12 lines

java

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

configureFor("localhost", 8080);

stubFor(get(urlPathEqualTo("/turbines/WTG-0912/status"))
    .willReturn(aResponse().withStatus(200)
        .withBody("{\"turbineId\":\"WTG-0912\",\"state\":\"CURTAILED\"}")));

resetAllRequests();     // journal only        -> DELETE /__admin/requests
resetAllScenarios();    // scenario state only -> POST /__admin/scenarios/reset

// The stub above still answers: neither call touches the stub set.

go deeper

for a junior

Know that WireMock has more than one reset. resetRequests() clears the record of what arrived; resetScenarios() puts stateful stubs back at their starting point. Neither of them deletes a stub mapping.

for a middle

Explain the store split. WireMock's journal and its scenario state live in different places, so resetRequests() reaches the journal and resetScenarios() returns each scenario to its initial state, with no overlap between them.

for a senior

Diagnose from symptoms. A stateful turbine-status sequence answering with the wrong step of the conversation points at scenario state, not the journal, and calling the wrong narrow reset will look as if it did nothing at all.

for a principal

Decide how much stateful stubbing you want in the estate. Sequences that need resetScenarios() to stay honest carry a real cost; say when that cost is worth paying and what you require of a suite that takes it on.

Two stores that look like one

WireMock records two very different kinds of history about a running server, and because both feel like "what has happened so far", they are constantly confused.

The request journal is a log. It holds the requests the server actually received, so anything that counts or inspects traffic reads it.
Scenario state is a position. Each stateful sequence sits on one named state at a time, and a matching request can advance it to the next.

One answers how many; the other answers where in the conversation are we. They live in separate stores, they are reset by separate calls, and neither call disturbs the other store.

The two calls, side by side

WireMock call	what it reaches	what it leaves alone
`resetRequests()`	the request journal	the stub set, scenario state, global settings
`resetScenarios()`	scenario state, returned to the initial state	the stub set, the request journal, global settings

Two details are worth having exactly right.

Neither call removes a stub mapping. After either one, every mapping is still registered and still answering, which is precisely why they are the safe pair on a shared server.
The initial state a scenario is returned to is the string "Started", exposed as Scenario.STARTED. It is a string constant and not an enum value, which matters the moment you try to compare it or set it by hand.

From the static client DSL the same two operations are WireMock.resetAllRequests() and WireMock.resetAllScenarios(), and on the admin API they are DELETE /__admin/requests and POST /__admin/scenarios/reset. WireMock also exposes resetScenario( for rewinding one named scenario rather than all of them.

What goes wrong when you call the wrong one

The failures are quiet, which is what makes them expensive.

You rewind scenarios and expect the counts to start again. They do not; the journal still holds everything from before, so a count reads higher than the case that just ran can explain.
You empty the journal and expect a stateful turbine-status sequence to answer from the beginning. It does not; the sequence carries on from wherever it was, so the first request of the next case gets the reply intended for the third request of the previous one.
You call one of them and conclude that "reset does nothing" because the symptom you were chasing lived in the other store. This is the commonest version, and it usually ends with somebody escalating to resetAll() and creating a much larger problem.

Reading the symptom to pick the call

Work from what the failure looks like rather than from which call you happen to remember.

A count that is too high, with correct response bodies, points at the journal.
A correct count with the wrong response body, on a mapping that declares a sequence, points at scenario state.
A response that is missing altogether, rather than wrong, points at the stub set and therefore at neither of these two calls.
A setting that carried over from an earlier case points at global settings, which no reset call reaches at all.

The same split in another product

Mountebank draws the line in the same place but addresses it as a resource, and Mountebank's DELETE /imposters/:id/savedRequests clears one imposter's recorded requests while leaving that imposter and its stubs in place. The lesson generalises even though the spelling does not -- a stub server's recorded traffic and its stubbing configuration are separate things, and a well-built suite says which of the two it wants cleared.

Why this is worth knowing precisely

On a turbine-status suite, the two stores fail in ways that look alike from the outside: a case that should have seen one call to /turbines/WTG-0912/status sees three, or a case that expected a PRODUCING body gets a CURTAILED one. Both read as flakiness. The difference is entirely in which store carried state across, and once you can name the store you can name the call in one step instead of reaching for the broadest reset and hoping. That habit -- store first, call second -- is what keeps a shared stub server usable for more than one suite at a time.

## Two stores that look like one WireMock records two very different kinds of history about a running server, and because both feel like "what has happened so far", they are constantly confused. - The **request journal** is a log. It holds the requests the server actually received, so anything that counts or inspects traffic reads it. - **Scenario state** is a position. Each stateful sequence sits on one named state at a time, and a matching request can advance it to the next. One answers *how many*; the other answers *where in the conversation are we*. They live in separate stores, they are reset by separate calls, and neither call disturbs the other store. ## The two calls, side by side | WireMock call | what it reaches | what it leaves alone | |---|---|---| | `resetRequests()` | the request journal | the stub set, scenario state, global settings | | `resetScenarios()` | scenario state, returned to the initial state | the stub set, the request journal, global settings | Two details are worth having exactly right. 1. Neither call removes a stub mapping. After either one, every mapping is still registered and still answering, which is precisely why they are the safe pair on a shared server. 2. The initial state a scenario is returned to is the string `"Started"`, exposed as `Scenario.STARTED`. It is a string constant and not an enum value, which matters the moment you try to compare it or set it by hand. From the static client DSL the same two operations are `WireMock.resetAllRequests()` and `WireMock.resetAllScenarios()`, and on the admin API they are `DELETE /__admin/requests` and `POST /__admin/scenarios/reset`. WireMock also exposes `resetScenario(` for rewinding one named scenario rather than all of them. ## What goes wrong when you call the wrong one The failures are quiet, which is what makes them expensive. - You rewind scenarios and expect the counts to start again. They do not; the journal still holds everything from before, so a count reads higher than the case that just ran can explain. - You empty the journal and expect a stateful turbine-status sequence to answer from the beginning. It does not; the sequence carries on from wherever it was, so the first request of the next case gets the reply intended for the third request of the previous one. - You call one of them and conclude that "reset does nothing" because the symptom you were chasing lived in the other store. This is the commonest version, and it usually ends with somebody escalating to `resetAll()` and creating a much larger problem. ## Reading the symptom to pick the call Work from what the failure looks like rather than from which call you happen to remember. - A count that is too high, with correct response bodies, points at the journal. - A correct count with the wrong response body, on a mapping that declares a sequence, points at scenario state. - A response that is missing altogether, rather than wrong, points at the stub set and therefore at neither of these two calls. - A setting that carried over from an earlier case points at global settings, which no reset call reaches at all. ## The same split in another product Mountebank draws the line in the same place but addresses it as a resource, and Mountebank's `DELETE /imposters/:id/savedRequests` clears one imposter's recorded requests while leaving that imposter and its stubs in place. The lesson generalises even though the spelling does not -- a stub server's recorded traffic and its stubbing configuration are separate things, and a well-built suite says which of the two it wants cleared. ## Why this is worth knowing precisely On a turbine-status suite, the two stores fail in ways that look alike from the outside: a case that should have seen one call to `/turbines/WTG-0912/status` sees three, or a case that expected a `PRODUCING` body gets a `CURTAILED` one. Both read as flakiness. The difference is entirely in which store carried state across, and once you can name the store you can name the call in one step instead of reaching for the broadest reset and hoping. That habit -- store first, call second -- is what keeps a shared stub server usable for more than one suite at a time.

Does WireMock's resetAll() make resetScenarios() unnecessary?
In effect yes, but for a reason worth stating. `resetAll()` delegates to `resetToDefaultMappings()`, which tears the stub set down and rebuilds it, and scenario state belongs to the mappings that declare it. Scenarios therefore come back at their initial state as a side effect of the rebuild, not because a scenario reset ran.
If a scenario is mid-sequence, what does resetRequests() change about it?
Nothing at all. `resetRequests()` resets the request journal only, so a scenario sitting on its second or third state stays there and the next matching request advances it from that point. The counts start again from zero while the conversation carries on, and that pairing is exactly what produces confusing turbine-status results.
How do you rewind one scenario rather than all of them?
WireMock exposes `resetScenario(` for a single named scenario, alongside `resetAllScenarios()` for every one. Rewinding just the sequence a case touched is the narrower move and leaves any other stateful mapping on the server where it was, which matters when more than one suite is using the instance.

Think of a stopwatch sitting beside a dial. WireMock's request journal is the stopwatch and a scenario's state is the dial: resetting the stopwatch does not turn the dial back, and turning the dial back does not clear the stopwatch.

saying these in an interview costs you the question

Thinks one reset call covers both stores
Believes resetScenarios() also clears the request journal
Expects either call to delete a stub mapping
Treats Scenario.STARTED as an enum constant, not a string
Assumes a scenario rewinds whenever its stub is re-registered

In WireMock, how does resetScenarios() differ from resetRequests() on a turbine-status stub server?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two stores that look like one

The two calls, side by side

What goes wrong when you call the wrong one

Reading the symptom to pick the call

The same split in another product

Why this is worth knowing precisely

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

Two stores that look like one

The two calls, side by side

What goes wrong when you call the wrong one

Reading the symptom to pick the call

The same split in another product

Why this is worth knowing precisely

answer

go deeper