skip to content

What does Mockito.verify do, and how does it differ from a stub set up with when/thenReturn?

level: juniorimportance: must knowfreq 80%

answer

  1. verify = assert a call happened
  2. when/thenReturn = stub a return value
  3. verify is for void / side-effect calls
  4. behavior vs state verification
  5. stub before, verify after

basics

~10 s

verify checks that a method was actually called on a mock (an interaction). when/thenReturn instead sets up what a method returns when called. verify asserts behavior happened; stubbing controls return values.

solid answer

~40 s

Mockito.verify is used in the assertion phase of a test to confirm that a specific method was called on a mock with given arguments and a given number of times. It tests interactions (behavior verification) rather than return values. when(...).thenReturn(...) is the opposite end: it is stubbing, configured before the call, telling the mock what to give back. A typical test stubs the collaborators it needs to drive the code, exercises the system under test, then verifies the side-effecting calls that have no return value to assert on (e.g. repository.save, emailSender.send). Stubbing answers 'what does this return?'; verify answers 'was this called, how, and how often?'. Over-verifying interactions that a return-value assertion already covers makes tests brittle, so prefer state assertions where possible and reserve verify for void/side-effect calls.

go deeper

for a junior

Can state that verify checks a method was called and when/thenReturn sets a return value, and write a basic verify(mock).method().

for a middle

Knows verify is for side effects/void methods, places it in the assert phase, and avoids redundant verification when a state assertion suffices.

for a senior

Articulates behavior vs state verification, the brittleness trade-off, and chooses verify deliberately for interaction contracts rather than as a default.

for a principal

Frames verification strategy across a test suite — when interaction tests encode a real contract vs when they ossify implementation — and guides the team toward state-based testing where feasible.

## The two halves of a mock A **mock** is a fake object that stands in for a real collaborator (a dependency your code calls). Mockito mocks have two distinct jobs, and `verify` is only one of them. **1. Stubbing (input side).** `when(mock.foo()).thenReturn(x)` tells the mock: 'when someone calls `foo()`, give back `x`.' This is configured **before** you run the code under test, and it controls what the mock *provides*. It does not assert anything. **2. Verification (output/interaction side).** `verify(mock).foo()` is an **assertion**: it checks, *after* the code ran, that `foo()` was in fact called on the mock. If it was never called, the test fails. This is called **behavior verification** (as opposed to **state verification**, where you assert on a returned value or an object's fields). ## Why two kinds exist Some methods return a value you can assert on directly (`assertEquals(expected, service.compute())`). Others are **void** or side-effecting: `repository.save(user)`, `emailSender.send(msg)`, `logger.warn(...)`. There is no return value to check, so the only way to prove your code did the right thing is to verify the interaction happened. That is `verify`'s reason to exist. ## The test phases A Mockito test usually follows arrange / act / assert: ``` // arrange: stub what the code needs when(repo.findById(1L)).thenReturn(Optional.of(user)); // act: run the system under test service.deactivate(1L); // assert: verify the side effect verify(repo).save(user); ``` Note stubbing comes first (it shapes inputs), `verify` comes last (it checks outputs). ## verify vs when — common confusions - `verify(mock).foo()` does **not** stub; calling it does not make `foo()` return anything special. - `when(mock.foo())` does **not** assert; if `foo()` is never called, a plain stub does **not** fail the test (unless you use strict stubs / `verify`). - `verify` records the call against the mock's interaction log; Mockito then matches it against what actually happened. ## Argument matching `verify(mock).foo("a")` passes only if `foo` was called with an argument equal to `"a"` (by `equals`). You can loosen this with matchers like `any()`, `eq(...)`, `argThat(...)`. ## When NOT to verify If a return-value assertion already proves the behavior, adding a redundant `verify` couples the test to *how* the code works (its calls), making it brittle when you refactor. Prefer state assertions; use `verify` mainly for void side effects.

  • If a method returns a value, should you verify the call or assert on the return value?
    Prefer asserting on the return value (state verification) — it is less brittle. Reserve verify for void/side-effecting methods that have no return value to assert on.
  • Does verify need the call to have been stubbed first?
    No. verify works on any method call recorded against the mock; stubbing is independent. An unstubbed call still returns Mockito's default (null/0/false) and can still be verified.

saying these in an interview costs you the question

  • Thinking verify stubs a return value, or that when/thenReturn asserts a call happened
  • Verifying every interaction including ones a return-value assertion already covers (brittle tests)
  • Believing a plain unmatched stub fails the test like verify does

context

resolving links…