What does a freshly created, unstubbed Mockito mock return when its methods are called, for various return types?
answer
- objects -> null
- numbers -> 0, boolean -> false
- collections -> EMPTY, not null
- Optional -> Optional.empty()
- default Answer = RETURNS_DEFAULTS
basics
~20 sAn unstubbed mock returns safe empty defaults: null for objects, 0 for numbers, false for booleans, and empty collections (an empty list/set/map, not null). So calling a method you didn't stub won't throw on its own.
solid answer
~40 sA fresh mock has no programmed behaviour, but every method must still return something, so Mockito supplies type-appropriate defaults via its default answer (RETURNS_DEFAULTS). Object references return null. Numeric primitives (int, long, double, etc.) return 0; boolean returns false; char returns the null character. Crucially, collection and container return types return empty instances rather than null — empty List, Set, Map, Stream, and Optional.empty() — so iterating the result of an unstubbed call is safe and won't NPE. This is why you only stub the calls your assertion actually depends on; everything else returns a harmless default. void methods simply do nothing. You can change this policy globally by creating the mock with a different Answer, e.g. mock(Foo.class, RETURNS_DEEP_STUBS) or RETURNS_SMART_NULLS, but the empty-default behaviour is the sensible out-of-the-box contract.
go deeper
Knows the basic defaults: null for objects, 0/false for primitives, empty collections.
Can name Optional.empty() and explain why empty-collection defaults prevent NPEs and reduce needed stubbing.
Knows the default is a pluggable Answer (RETURNS_DEFAULTS) and can name alternatives like RETURNS_SMART_NULLS/RETURNS_DEEP_STUBS and their trade-offs.
Reasons about default-answer choices as a team convention, the risks of RETURNS_DEEP_STUBS hiding Law-of-Demeter violations, and how defaults interact with strict-stubbing test hygiene.
## Why defaults exist at all When you create a mock with `mock(SomeType.class)`, none of its methods have been **stubbed** (programmed). But Java still requires every non-`void` method to return a value of the declared type. Mockito therefore consults a **default Answer** for any call you have not explicitly scripted. An `Answer<T>` is Mockito's strategy interface for 'what should this unstubbed call return?'. The out-of-the-box default is `RETURNS_DEFAULTS`, backed internally by the `ReturnsEmptyValues` answer. ## The exact defaults | Declared return type | Default returned | |---|---| | Any object reference (`String`, `Order`, custom types) | `null` | | `boolean` / `Boolean` | `false` | | `int`, `long`, `short`, `byte`, `double`, `float` | `0` (zero of that type) | | `char` | `'\u0000'` (the null character) | | `List`, `Collection`, `Iterable` | empty `List` | | `Set` | empty `Set` | | `Map` | empty `Map` | | `Stream` | empty `Stream` | | `Optional` | `Optional.empty()` | | array | empty array (length 0) | | `void` | nothing happens (no exception) | The key design choice is the **collection/container row**: Mockito returns an *empty* collection, never `null`. This matters because real code very often does `for (X x : collaborator.getThings())` or `collaborator.find().stream()...`. If the default were `null`, every unstubbed call feeding such a loop would throw `NullPointerException`, forcing you to stub calls you do not care about. By returning empty containers, Mockito lets you stub **only** what the specific test asserts on. ## Practical consequence ```java OrderRepository repo = mock(OrderRepository.class); repo.findById(99L); // returns null (Optional<Order>? -> actually Optional.empty()) repo.findAll(); // returns an empty List, NOT null repo.count(); // returns 0L repo.exists(5L); // returns false ``` So a test can construct the SUT, call it, and only the *relevant* collaborator methods need `when(...).thenReturn(...)`. Unstubbed calls silently fall through to defaults. ## Note on Optional/null and `findById` If a method's declared return type is `Optional<Order>`, the default is `Optional.empty()` (a container), not `null`. If the method returns the bare object `Order`, the default is `null`. The rule is about the *declared static type*, not the value you expect. ## Overriding the default answer You can pass a different global `Answer` at creation: - `RETURNS_SMART_NULLS` — instead of a plain `null`, returns a placeholder that throws a more helpful `SmartNullPointerException` (telling you which unstubbed call produced the null) if you later dereference it. Useful while debugging NPEs. - `RETURNS_DEEP_STUBS` — auto-mocks the return value too, so `a.getB().getC()` works without stubbing each level (use sparingly; it hides design issues). - `RETURNS_MOCKS` — returns mocks for mockable types instead of null. - A custom `Answer` lambda for bespoke logic. ```java Foo foo = mock(Foo.class, RETURNS_SMART_NULLS); ``` But for everyday tests, the empty-value default is exactly what you want, and understanding it explains why so many Mockito tests stub surprisingly few methods.
- Why does Mockito return empty collections instead of null by default?So that code which iterates or streams the result of an unstubbed call doesn't NPE, letting you stub only the calls your assertion depends on rather than every method that happens to be invoked.
- How would you make a mock surface unstubbed-null usages more loudly?Create it with RETURNS_SMART_NULLS, which returns a placeholder that throws a descriptive SmartNullPointerException when dereferenced, pointing at the unstubbed call.
saying these in an interview costs you the question
- Claiming an unstubbed collection method returns null (it returns an empty collection)
- Saying an unstubbed call throws an exception by default — it does not (with the standard default answer)
- Thinking you must stub every method to avoid crashes
- Confusing the default for Optional (empty) with the default for a bare object (null)