skip to content

BDDMockito is pure aliasing. Given that, what guidance would you give a team about adopting it, and what subtle pitfalls should they watch for?

level: seniorimportance: nice to knowfreq 28%

answer

  1. Aliases only — decide on readability, not metrics
  2. One style per test/codebase; don't mix given()+verify()
  3. Void stubbing flips: willThrow().given(mock).m()
  4. Strict stubbing (UnnecessaryStubbing) unchanged
  5. then(mock) vs AssertJ then(value) import clash

basics

~20 s

Pick one style per test (or per codebase) and stay consistent. Don't mix given() with verify() in the same test. Remember void stubbing flips order. Otherwise it behaves exactly like normal Mockito, so there are no new runtime risks.

solid answer

~50 s

Because BDDMockito is purely an alias layer, the guidance is about consistency, not capability. Decide one convention — classic when()/verify() or BDD given()/then() — and apply it per test, ideally per codebase, so readers aren't switching vocabularies. Avoid mixing given() with verify() in a single test; it compiles but reads incoherently. Know the gotchas: void stubbing inverts to willThrow(ex).given(mock).voidMethod(); given() in void form takes the mock, not a call; and unnecessary stubs still trigger Mockito's strict-stubbing UnnecessaryStubbingException regardless of which vocabulary you use. There's no performance or behavioral difference, so don't justify the choice on anything but readability and team familiarity. For teams already practicing BDD or using a BDD assertion library (AssertJ, Spock-like phrasing), BDDMockito aligns naturally; for teams steeped in classic Mockito, the switch buys little. The deciding factor is one consistent, self-documenting style.

go deeper

for a junior

Understands it is the same as Mockito and should pick whichever style the codebase uses.

for a middle

Avoids mixing styles, knows the void-stubbing inversion, and recognizes there is no behavioral difference.

for a senior

Sets a per-test/per-codebase convention, anticipates the then() import clash with AssertJ, and knows strict stubbing is unaffected.

for a principal

Establishes and enforces a team-wide testing idiom, weighs the churn of switching styles against readability gains, and ensures consistency across many modules rather than per-developer preference.

## The core fact `BDDMockito` adds **no behavior** — every method delegates to the identical Mockito engine. So every piece of guidance is about *style and consistency*, never about power, correctness, or speed. ## Adoption guidance 1. **Choose one vocabulary and standardize it.** Either classic `when()/verify()` or BDD `given()/then()`. Consistency matters more than the choice itself; a reviewer scanning a file should not have to context-switch between two naming systems. 2. **Don't mix styles within a test.** `given(repo.find()).willReturn(x); ... verify(repo).save(y);` compiles and runs, but reads incoherently — half BDD, half classic. If you go BDD, verify with `then(repo).should().save(y)`. 3. **Base the decision on readability, not metrics.** There is no runtime difference, so 'it's faster' or 'it's safer' are wrong justifications. The only real benefit is that tests read as Given-When-Then. 4. **Fit it to surrounding conventions.** If the team already uses BDD assertion phrasing (e.g., AssertJ's fluent style) or practices BDD, `given/then` aligns nicely. If the codebase is overwhelmingly classic Mockito, churn-to-switch may not be worth it. ## Subtle pitfalls - **Void-stubbing order flips.** You cannot write `given(mock.voidM())` because a void call returns nothing to wrap. The BDD form is `willThrow(ex).given(mock).voidM()` / `willDoNothing().given(mock).voidM()` — note `given(mock)` takes the **mock object**, not a method call. This mirrors classic `doThrow().when(mock).voidM()`. - **Strict stubbing still applies.** Modern Mockito (JUnit 5 `@ExtendWith(MockitoExtension.class)` or `Strictness.STRICT_STUBS`) throws `UnnecessaryStubbingException` for a stub that is never used and `PotentialStubbingProblem` for argument mismatches — *regardless* of whether you wrote `given()` or `when()`. BDDMockito does not change strictness. - **`then` name collision.** BDDMockito's `then(mock)` (verification) can be confused with AssertJ's `then(value)` (an assertion entry point) if both are static-imported. Import them carefully or qualify one to avoid an ambiguity that the compiler may or may not flag depending on signatures. - **`then(mock).should()` still needs an actual method call after it.** `then(mock).should()` alone verifies nothing; you must chain the expected invocation: `then(mock).should().save(x)`. - **No new matcher rules.** Argument matchers (`any()`, `eq()`), the all-or-none matcher rule, and `ArgumentCaptor` behave identically. Don't expect BDDMockito to relax any of them. ## When it genuinely helps It shines when the team values tests-as-specifications and writes the `// given / // when / // then` structure deliberately. It is neutral-to-pointless when the team is happy with classic Mockito and would only introduce two competing idioms. ## Bottom line BDDMockito is a readability convention. Standardize on one style, respect the void-stubbing inversion, remember strict-stubbing is unchanged, and watch the `then` import collision. Beyond that, it is just Mockito.

  • Does using BDDMockito change how Mockito's strict stubbing treats an unused stub?
    No. Strict stubbing (e.g., MockitoExtension or STRICT_STUBS) still throws UnnecessaryStubbingException for an unused given()/willReturn(), exactly as it would for when()/thenReturn(). The vocabulary is irrelevant to strictness.
  • What import-level conflict can arise when combining BDDMockito with AssertJ?
    Both expose a static then(...): BDDMockito's then(mock) for verification and AssertJ's then(value) for assertions. Static-importing both can create ambiguity; qualify or import selectively to avoid confusion.

saying these in an interview costs you the question

  • Justifying BDDMockito on performance or 'safer mocking' grounds — it is identical behavior.
  • Mixing given() stubs with verify() verifications in one test.
  • Assuming BDDMockito relaxes strict stubbing or matcher rules.
  • Forgetting that then(mock).should() must be followed by the expected method call.

context

resolving links…