Mockito ships an AdditionalAnswers utility class alongside hand-written Answer lambdas. Which helpers does it provide, and when would you use them instead of writing the lambda yourself?

## Why a helper class exists A handful of `Answer` shapes come up in nearly every codebase. Rather than have everyone rewrite `inv -> inv.getArgument(0)`, Mockito collects them as static factories on `org.mockito.AdditionalAnswers`. They are ordinary `Answer` objects, so they plug into `thenAnswer(...)` (or `willAnswer(...)` in BDD style) exactly like a lambda. ```java import static org.mockito.AdditionalAnswers.returnsFirstArg; when(repo.save(any(User.class))).thenAnswer(returnsFirstArg()); ``` ## Argument-echo helpers `returnsFirstArg()`, `returnsSecondArg()`, `returnsLastArg()` and the positional `returnsArgAt(int)` all return one argument of the call. The value over a raw lambda is intent: `returnsFirstArg()` says "this collaborator hands the object back" without the reader decoding an index and a cast. `returnsLastArg()` is particularly useful for signatures ending in the interesting parameter, and survives a signature change that adds a leading parameter. ## Sequence helper `returnsElementsOf(Collection)` returns the collection's elements one per invocation. Consecutive `thenReturn(a, b, c)` covers the literal case, but `returnsElementsOf` shines when the sequence is built at runtime - generated ids, a list read from a fixture file, or a list parameterised by the test. Once the elements run out, Mockito keeps returning the last one rather than failing. ## Delegation `delegatesTo(Object target)` forwards each matching call to `target` by matching method signature reflectively, returning whatever the real object returns. Three situations make it valuable: 1. You want mostly real behaviour but still need `verify()` on the interactions - unlike a spy, the mock and the delegate stay separate objects, so calls the delegate makes to *itself* are not recorded. 2. The type cannot be spied cleanly (an interface you only have a hand-written in-memory implementation for). 3. A generated client interface (for example an RPC stub) can be backed by a simple in-process implementation while the test still asserts on calls. The delegate must expose signature-compatible methods; a mismatch fails at call time. And because the delegate is a different object, `this`-referencing behaviour inside it does not route back through the mock. ## Latency `answersWithDelay(long millis, Answer delegate)` sleeps the **calling thread** for the given number of milliseconds, then runs the delegate answer. It exists to test timeout handling, circuit breakers, retry budgets, and racy async code paths against a dependency that is deliberately slow. The cost is real wall-clock time in the suite, and sleeps are a classic source of flakiness on loaded CI machines - a 50 ms delay meant to beat a 100 ms timeout can lose that race. Use short delays, only where the timing is the thing under test, and prefer an injectable clock or a controllable scheduler when the production code allows it. ## Typed lambda adapters `AdditionalAnswers.answer(...)` and `answerVoid(...)` adapt small typed functional interfaces so you can write `answer((String name, Integer age) -> name + age)` instead of pulling arguments out of `InvocationOnMock` by index. This removes the unchecked casts and the index arithmetic, which is the main source of runtime surprises in hand-written answers. It is a readability win in any answer that consumes more than one argument. ## Choosing between helper and lambda Use a helper when one exists: it names the intent and is immune to index typos. Write a lambda when the behaviour is specific to this test - a value derived from the argument, a callback invocation, a conditional throw. Whichever you pick, the answer should be short enough to read at a glance; a large answer, helper-assembled or not, is a sign the test wants a fake rather than a mock.