skip to content

Map the core BDDMockito methods to their classic Mockito equivalents, including stubbing return values, throwing, and verification.

level: middleimportance: should knowfreq 50%

answer

  1. given = when, will* = then*
  2. willReturn / willThrow / willAnswer / willCallRealMethod
  3. void: willThrow(ex).given(mock).m() — order flips
  4. then(mock).should() = verify(mock)
  5. should(times(2)) = verify(mock, times(2))

basics

~10 s

given() replaces when(); willReturn() replaces thenReturn(); willThrow() replaces thenThrow(); and then(mock).should() replaces verify(mock). Same behavior, different names that read as Given-When-Then.

solid answer

~30 s

BDDMockito is a one-to-one rename of the classic API. For stubbing: when(mock.m()).thenReturn(v) becomes given(mock.m()).willReturn(v); thenThrow(ex) becomes willThrow(ex); thenAnswer(a) becomes willAnswer(a); and the call-real-method form thenCallRealMethod() becomes willCallRealMethod(). For void methods, doThrow(ex).when(mock).m() becomes willThrow(ex).given(mock).m() — the BDD form flips to start with will*. For verification, verify(mock).m() becomes then(mock).should().m(), and verify(mock, times(2)).m() becomes then(mock).should(times(2)).m(); then(mock).shouldHaveNoInteractions() mirrors verifyNoInteractions(mock). All of these are static methods on org.mockito.BDDMockito, usually static-imported. Because they are aliases, the matchers, argument captors, and verification modes (times, never, atLeast) all work identically.

code

java · 15 lines
java
// value return
given(repo.count()).willReturn(3L);              // when().thenReturn()
// throw
given(repo.findById(9L)).willThrow(new NotFound()); // when().thenThrow()
// dynamic answer
given(repo.save(any())).willAnswer(inv -> inv.getArgument(0));

// void method (order flips: starts with will*)
willThrow(new IllegalStateException())
    .given(repo).deleteById(0L);                  // doThrow().when()

// verification
then(repo).should().save(user);                   // verify(repo).save(user)
then(repo).should(times(2)).flush();              // verify(repo, times(2)).flush()
then(repo).shouldHaveNoMoreInteractions();        // verifyNoMoreInteractions(repo)

go deeper

for a junior

Can translate the simple given().willReturn() and then().should() cases and recognize willThrow.

for a middle

Knows the full alias table including willAnswer/willCallRealMethod and the should(times(...)) verification modes.

for a senior

Fluently handles the void-stubbing order flip (willThrow(ex).given(mock).m()) and knows shouldHaveNoInteractions / shouldHaveNoMoreInteractions.

for a principal

Can explain why the void form must invert (no value to wrap) and ensures the team applies one consistent translation convention across a codebase.

## The mapping at a glance BDDMockito is a **complete rename** of the parts of Mockito you use most. Knowing the table lets you translate any test in either direction. Below, the left column is classic Mockito, the right is the BDD alias. ### Stubbing a value-returning method | Classic | BDD | |---|---| | `when(mock.m()).thenReturn(v)` | `given(mock.m()).willReturn(v)` | | `when(mock.m()).thenThrow(ex)` | `given(mock.m()).willThrow(ex)` | | `when(mock.m()).thenAnswer(a)` | `given(mock.m()).willAnswer(a)` | | `when(mock.m()).thenCallRealMethod()` | `given(mock.m()).willCallRealMethod()` | | `when(mock.m()).thenReturn(a, b)` | `given(mock.m()).willReturn(a, b)` (consecutive returns) | Here `mock` is the fake object, `m()` the method being stubbed, `v` the value to return, `ex` an exception (instance or class), and `a` an `Answer` (a callback that computes the result from the invocation). ### Stubbing a void method (the order flips) For methods that return `void`, you cannot write `given(mock.voidM())` because the call has no value to wrap, so Mockito offers a *do-form* that starts with the action. BDDMockito mirrors it with a *will-form*: | Classic | BDD | |---|---| | `doThrow(ex).when(mock).voidM()` | `willThrow(ex).given(mock).voidM()` | | `doNothing().when(mock).voidM()` | `willDoNothing().given(mock).voidM()` | | `doAnswer(a).when(mock).voidM()` | `willAnswer(a).given(mock).voidM()` | Note that here `given` takes the **mock itself** (`given(mock)`), not the method call — this is the void-stubbing shape, analogous to `when(mock)` in the do-form. ### Verification *Verification* asserts a call happened. BDDMockito reads it as a 'then' step: | Classic | BDD | |---|---| | `verify(mock).m()` | `then(mock).should().m()` | | `verify(mock, times(2)).m()` | `then(mock).should(times(2)).m()` | | `verify(mock, never()).m()` | `then(mock).should(never()).m()` | | `verifyNoInteractions(mock)` | `then(mock).shouldHaveNoInteractions()` | | `verifyNoMoreInteractions(mock)` | `then(mock).shouldHaveNoMoreInteractions()` | The `should(...)` method accepts the same **verification modes** (`times`, `never`, `atLeast`, `atMost`, `only`) as the classic `verify`'s second argument. ## Why the names matter - `given` = the **Given/Arrange** step (program the collaborator). - `then(mock).should()` = the **Then/Assert** step (the mock should have been called). - The actual **When** is just calling the system under test between the two — no Mockito call needed for it. ## Important: aliases only Every alias delegates to the identical underlying machinery, so **argument matchers** (`any()`, `eq()`), **ArgumentCaptor**, and **verification modes** behave exactly the same. You gain nothing in power; you gain readability. Mixing `given(...)` with `verify(...)` compiles and runs, but defeats the point.

  • How do you stub a void method with BDDMockito, and why is it different from a returning method?
    Use the will-form that starts with the action: willThrow(ex).given(mock).voidMethod() or willDoNothing().given(mock).voidMethod(). A void call has no value to wrap in given(...), so — like classic doThrow().when() — you put will* first and pass the mock itself to given().
  • How do you express verify(mock, times(2)) in BDD form?
    then(mock).should(times(2)).method(). The should() call takes the same verification mode object that verify's second argument takes.

saying these in an interview costs you the question

  • Writing given(mock.voidMethod()).willThrow(...) for a void method — it does not compile; use willThrow(...).given(mock).voidMethod().
  • Thinking willReturn/willThrow change matcher or captor behavior (they do not).
  • Forgetting that should() takes verification modes, and instead inventing should(times(2)).times(2).

context

resolving links…