In a Mockito test the same collaborator call is stubbed twice - once in a @BeforeEach setup method and again at the top of a single test. Which stubbing wins, and what else should you know about overriding stubs?

## How Mockito resolves a call Each mock keeps its stubbings in an ordered list, appended as they are registered. When a call arrives, Mockito walks that list from the **most recent** backwards and uses the first stubbing whose method and argument matchers accept the invocation. So among stubbings that match the same call, the last one registered wins - for every call after it was registered. Earlier stubbings are not removed or replaced. They stay in the list, unreachable while a newer one shadows them, and would come back into play if the newer stubbing were narrower and a differently-argued call arrived. ## Setup plus per-test override This is why the common pattern works: ```java @BeforeEach void setUp() { when(repo.findById(anyLong())).thenReturn(defaultUser); } @Test void missingUser() { when(repo.findById(99L)).thenReturn(null); // registered later -> wins for 99 ... } ``` Calls with `99L` hit the newer stubbing; every other id still falls through to the broad one. This is genuine layering and is worth keeping. ## The strictness interaction When the override is *exactly* as broad as the setup stub and the setup stub is therefore never used, Mockito's strict mode complains. With `MockitoExtension` (JUnit 5) or `MockitoJUnitRunner.Strict`, `Strictness.STRICT_STUBS` is the default, and it fails the test class with `UnnecessaryStubbingException`, naming the file and line of the unused stubbing. That is a useful signal rather than an obstacle. It is telling you the shared setup is not actually shared - some tests want a different value - so the stubbing belongs in the tests that use it. Options, in order: 1. Move the stubbing into the tests that need it (best). 2. Keep the setup stub broad and only override for specific arguments, so both are genuinely used. 3. Mark the setup stubbing `lenient()` when it truly is optional background for most tests - acceptable, but each `lenient()` is a small waiver you should be able to justify. Strict stubs also flags a related case, `PotentialStubbingProblem`: the code called a stubbed method with arguments that no stubbing matches while a stubbing for different arguments exists. That usually means the production code built its arguments differently than the test assumed - a real bug caught early, not a framework annoyance. ## Consecutive values versus re-stubbing `when(x.get()).thenReturn(a, b)` registers one stubbing that yields `a` on the first call and `b` on the second, with `b` repeating thereafter. Re-stubbing the same call registers a **new** stubbing that shadows the whole sequence from that point on; it does not extend it. If you write the same `when(...).thenReturn(...)` inside a loop expecting a queue of values, you get N stubbings where only the last is ever consulted. ## Where re-stubbing actually hurts - **Mid-test re-stubbing to change behaviour halfway through an action** makes the test read like a script and hides which value applied at which moment. Consecutive stubbing, or an argument-dependent answer, expresses it more honestly. - **Re-stubbing on a spy** goes through the recording mechanism and therefore invokes the real method again during the `when(...)` expression - a second real side effect. - **reset(mock)** wipes stubbings *and* recorded interactions. The documentation itself treats it as a code smell: it usually means one test is exercising two scenarios, and splitting the test removes the need. It is occasionally defensible for an expensive mock in a shared container-managed context, but it should be an explicit, commented decision. ## What good looks like Keep `@BeforeEach` stubbing to the calls every test in the class genuinely needs, with values no test disagrees with. Put scenario-specific behaviour in the test. Let strict stubs delete the leftovers for you: an `UnnecessaryStubbingException` is a free review comment saying "this setup is lying about being shared". ## The interview-sized answer "Last matching stubbing wins, because Mockito scans newest-first. The earlier one is not removed - and if it is never used, strict stubs will fail the class with UnnecessaryStubbingException, which is the right signal to move the stub into the tests that need it. Broad-in-setup plus narrow-in-test is fine, because both are used."