Mocking a fluent builder in Mockito usually breaks with a NullPointerException on the second chained call. Why, and how does the Answers.RETURNS_SELF default answer fix it?

## Why chained calls break on a mock A fluent API is a convention, not a language feature: each configuring method happens to `return this`. When you mock the type, none of that implementation exists. Every method is intercepted, and an unstubbed one is answered by the mock's default answer, which for object return types is `null`. So the first call in the chain returns `null`, and the second call is invoked on `null` — a `NullPointerException` at the second link, with a message that looks nothing like "you mocked a builder". The manual workaround is to stub each link back to the mock: `when(builder.name(any())).thenReturn(builder);` repeated per method, which is noisy and needs updating whenever the builder gains a method. ## What RETURNS_SELF does `Answers.RETURNS_SELF` supplies `ReturnsSelf` as the default answer. On an unstubbed invocation it asks a simple question: *is the invoked method's declared return type assignable from the type of this mock?* If yes, it returns the mock itself. If no, it delegates to `ReturnsEmptyValues` — the ordinary `RETURNS_DEFAULTS` behaviour. That assignability rule is what makes it well behaved in practice: - `Builder name(String)` returns the mock → the chain continues; - `Builder self()` on a supertype return, e.g. `AbstractBuilder`, still returns the mock, because the mocked type is assignable to it; - `Product build()` returns the ordinary default (`null`), because `Product` is not a supertype of the builder — so you stub the terminal call explicitly, which is exactly the value your test cares about. Generics with self types (`B extends Builder<B>`) work at runtime because erasure leaves the raw supertype, which is still assignable. ## How to configure it ```java @Mock(answer = Answers.RETURNS_SELF) HttpRequestBuilder request; ``` or imperatively: ```java HttpRequestBuilder request = mock(HttpRequestBuilder.class, Answers.RETURNS_SELF); // or, when other settings are needed: mock(HttpRequestBuilder.class, withSettings().defaultAnswer(RETURNS_SELF).name("request")); ``` Verification works normally afterwards — `verify(request).timeout(Duration.ofSeconds(5))` — and because every link is the *same* mock instance, all the chained calls are recorded on one invocation container, which also means `verify(request, times(3))` counts across the whole chain if you use the same method. ## When to use it, and when not to The honest answer in an interview includes the design caveat. If the builder is *your* class, mocking it is usually wrong: builders are cheap, deterministic, dependency-free value constructors, and using the real one produces a stronger test with no stubbing at all. Reach for `RETURNS_SELF` when the fluent type belongs to someone else and is expensive or awkward to instantiate — an HTTP client request builder, a cloud SDK request builder, a query DSL — and when what you actually want to assert is *which configuration calls were made*. Two comparisons interviewers like to draw: - **versus stubbing each link**: same effect, far less code, and it survives new methods on the builder. - **versus deep stubs**: deep stubs return a fresh mock of each return type and remember it so chains through *different* types work; `RETURNS_SELF` returns the same mock and only for self-returning methods. For a genuine builder, `RETURNS_SELF` is the narrower, more honest tool — the chain really is one object at runtime. A final gotcha: if the builder's terminal method returns a type the test then uses, remember it is still `null` unless stubbed. `RETURNS_SELF` deliberately does not auto-mock it.