A Mockito deep-stub chain still fails: one call in the middle returns null, and another throws ClassCastException on a method declared to return a generic type variable T. What are the limits of deep stubbing that explain both?

## How a deep stub decides what to return `RETURNS_DEEP_STUBS` is an `Answer`. On each unstubbed invocation it inspects the *declared* return type of the method and asks whether that type can be mocked. If yes, it creates a child mock (itself deep) and caches it against the invocation. If no, it delegates to the ordinary default answer — the same one an ordinary mock uses — which yields `0`/`false` for primitives, an empty collection for collection types, and `null` for everything else. So every failure of a deep chain comes down to one of two questions: *is this return type mockable?* and *does Mockito know what the return type actually is?* ## Limit 1: types Mockito will not mock Primitives obviously cannot be mocked, so `a.b().count()` returning `int` gives `0` — fine as a terminal, useless as a link. More surprising are the JDK types Mockito explicitly refuses: `String`, `Class`, and the primitive wrapper types. A chain that passes through a `String` gets `null` and NPEs on the next call. That is not a bug to work around; a `String` is a value, and the fix is to stub that link with a real string. `final` classes and `final` methods used to be a hard stop too. Since Mockito 5 the **inline mock maker is the default**, so final classes and final methods *are* mockable and a deep chain can traverse them (`Optional`, for instance, is `final`). On Mockito 4 or with the subclass mock maker configured, the same chain returns `null` at that link. This is a version-sensitive answer worth stating explicitly. ## Limit 2: erasure Mockito carries generic metadata as far as the reflection API allows. If a method is declared `List<Order> findAll()`, the deep stub knows the element type, so `when(repo.findAll().get(0).id()).thenReturn(7L)` can produce an `Order` mock. Likewise a mock created for a field whose declared type is `Repo<Order>` can resolve `T` from the field's generic signature. What it cannot do is invent information that erasure destroyed. A method declared `<T> T get(String key)` has erasure `Object` (or the declared bound). Mockito creates a mock of that bound and hands it back; the compiler has inserted a checkstyle cast at the call site, so you get `ClassCastException: Object$MockitoMock cannot be cast to Order` — typically on the very line where you are writing the stub, which is confusing until you know the cause. Raw types and wildcard-heavy signatures fail the same way. The fix is not to fight it: stub that one link explicitly. ```java Order order = mock(Order.class); when(registry.get("order")).thenReturn(order); when(order.id()).thenReturn(7L); ``` ## Limit 3: what a deep stub does not give you The auto-created children are *empty mocks*: every method on them returns a default until stubbed. So a deep stub gets you past the NPE, but a chain that ends in real data still needs a `thenReturn`. Teams sometimes assume deep stubbing populates the graph with sensible values; it does not, and a test that never stubs the leaf is usually asserting against `null` or `0` by accident. Deep stubs also do not apply to spies, and combining them with strict stubbing makes unused chain stubbings surface as `UnnecessaryStubbingException` — correct behaviour, but noisier than people expect when a chain is only partly exercised. ## Diagnosing quickly When a deep chain fails, walk it link by link and read the *declared* return type of each method. The first one that is a primitive, a `String`, a wrapper, or a bare type variable is your answer. Everything else about deep stubs follows from that single mockability test.