What is BDDMockito, and how does it change the way you write Mockito stubs and verifications?
answer
- Same engine, BDD vocabulary
- given().willReturn() == when().thenReturn()
- then().should() == verify()
- Fixes the when/When naming clash
- org.mockito.BDDMockito, static import
basics
~10 sBDDMockito is a Mockito helper class that renames the usual stubbing methods so tests read like Given-When-Then. Instead of when(mock.foo()).thenReturn(x) you write given(mock.foo()).willReturn(x). It does the same thing, just with friendlier wording.
solid answer
~40 sBDDMockito is a static helper in Mockito (org.mockito.BDDMockito) that provides Behavior-Driven-Development aliases for the standard Mockito API. The behavior is identical; only the vocabulary changes so a test reads in Given-When-Then form. For stubbing you use given(mock.method()).willReturn(value) instead of when(...).thenReturn(...); for verification you use then(mock).should().method() instead of verify(mock).method(). The intent is to make the Arrange section (the 'given' block) and the Assert section (the 'then' block) literally use the words 'given' and 'then', so the test structure mirrors the BDD narrative. You typically static-import the methods (given, then) from BDDMockito. It is purely cosmetic sugar over the same mocking engine, so you can mix it with the classic API, though for readability you should pick one style per test.
code
java · 18 linesimport static org.mockito.BDDMockito.given;
import static org.mockito.BDDMockito.then;
@Test
void activatesUser() {
// given
given(userRepo.findById(1L)).willReturn(Optional.of(alice));
// when
User result = service.activate(1L);
// then
then(userRepo).should().save(alice);
}
// Classic Mockito equivalent:
// when(userRepo.findById(1L)).thenReturn(Optional.of(alice));
// verify(userRepo).save(alice);go deeper
Can state that BDDMockito renames when/verify to given/then for Given-When-Then readability, and write a basic given().willReturn() stub.
Knows the full alias map (given/willReturn/willThrow, then().should()), uses static imports, and explains it is the same engine, not new behavior.
Articulates the when/When naming-clash motivation, treats it as a team readability convention, and avoids mixing styles within a test.
Frames BDDMockito as one of several test-readability idioms; sets a team-wide convention and can justify when consistency (one style) outweighs marginal expressiveness.
## What problem this solves **Mockito** is the most widely used mocking library for Java unit tests. A *mock* is a fake stand-in for a real collaborator (e.g., a repository or HTTP client) whose behavior you script, so you can test one class in isolation. With plain Mockito you *stub* (program a return value) like this: `when(repo.findById(1)).thenReturn(user)` and you *verify* (assert a call happened) like this: `verify(repo).save(user)`. **BDD** stands for **Behavior-Driven Development**, a style where tests are phrased as a narrative: **Given** some initial state, **When** an action happens, **Then** an outcome is expected. The plain Mockito words `when` and `verify` clash with that narrative: the BDD 'When' is the action under test, but Mockito's `when(...)` actually belongs to the *Given* (arrange) phase. That naming collision makes BDD-style tests read awkwardly. ## What BDDMockito is `org.mockito.BDDMockito` is a class of **static aliases** that rename the existing Mockito calls so they match the BDD vocabulary. Nothing about the underlying mechanism changes — it is the *same* Mockito engine, just different method names. The two main aliases: - **Stubbing:** `given(mock.method()).willReturn(value)` is the alias of `when(mock.method()).thenReturn(value)`. - **Verification:** `then(mock).should().method()` is the alias of `verify(mock).method()`. You normally `import static org.mockito.BDDMockito.given;` and `import static org.mockito.BDDMockito.then;`. ## How a test reads with it ``` // given given(userRepo.findById(1L)).willReturn(Optional.of(alice)); // when User result = service.activate(1L); // then then(userRepo).should().save(alice); ``` The comment markers `// given / // when / // then` now match the actual method names, so the test structure is self-documenting. ## Key terms - **Stub:** a scripted answer for a mock's method ("when asked X, return Y"). - **Verify:** an assertion that a mock method *was called* (with given arguments, a given number of times). - **Alias:** a second name for the same operation. BDDMockito adds no new capability; it only renames. ## Why it matters It is purely a readability/idiom choice. Teams that practice BDD or that want their unit tests to read as a Given/When/Then story adopt it. It is fully interoperable with classic Mockito, but mixing both styles in one test is discouraged because it defeats the readability goal.
- Does BDDMockito behave any differently at runtime from classic when/verify?No. It is the exact same mocking engine; BDDMockito methods are thin aliases. The only difference is the method names and the resulting readability.
- Can you mix given() and verify() in the same test?Yes, they are interoperable, but it is discouraged. Mixing the two vocabularies defeats the readability goal; pick one style per test.
Think of it like subtitles in your native dialect for a film you already understand: the movie (Mockito's behavior) is unchanged, but the words now match how you naturally narrate the story (Given-When-Then).
saying these in an interview costs you the question
- Claiming BDDMockito is a separate library or framework (it is a class inside Mockito).
- Saying it changes mock behavior or adds new matching power (it is purely cosmetic aliasing).
- Confusing Mockito's when() with the BDD 'When' step (the cause BDDMockito exists to fix).