In Mockito, what does Mockito.spy(new ArrayList<String>()) give you that Mockito.mock(ArrayList.class) does not — specifically, what happens when you call a method you never stubbed?

## Two kinds of Mockito-created object Both `mock()` and `spy()` return an instrumented object that records every call, so `verify()` works on either. What differs is what happens when a call arrives and no stubbing matches it — Mockito calls that the *default answer*. **Mock.** The default answer is `RETURNS_DEFAULTS`: the method body never runs and Mockito returns the zero value for the return type — `null` for objects, `0` for numerics, `false` for `boolean`, and empty collections/strings for a few container types (Mockito returns an empty list rather than null for `List`-returning methods, for instance). Nothing about the real class executes, so no field is touched, no exception is thrown from real logic, and constructors are not even called. **Spy.** The default answer is effectively "call the real method". You hand `spy()` an existing instance; Mockito builds an instrumented object of the same class, copies the original's fields into it, and lets unstubbed calls fall through to the genuine implementation running on that instrumented instance. ## Concretely ```java List<String> mocked = mock(ArrayList.class); mocked.add("a"); mocked.size(); // 0 — add() did nothing List<String> spied = spy(new ArrayList<String>()); spied.add("a"); spied.size(); // 1 — real behaviour verify(mocked).add("a"); // both record calls verify(spied).add("a"); ``` That `size() == 0` on the mock is the single most common beginner surprise: the object looks like a list, quacks like a list, and stores nothing. ## When each is right Use a **mock** for almost every collaborator. Unit tests want to control what a dependency returns and assert what was asked of it; running the dependency's real code defeats the isolation you were buying. A mocked `PaymentGateway` never touches the network; a mocked `Repo` never needs a database. Use a **spy** in two narrow situations: 1. **Real behaviour plus interaction assertions.** A small, side-effect-free helper whose real logic you want to keep, but where the test also needs to prove it was called with particular arguments. 2. **Legacy code you cannot restructure.** A class that does something untestable in one method — reads a file, calls a static, sleeps — where stubbing that one method is the cheapest way to get the rest under test until you can extract the dependency. Outside those, prefer the plain object. If you want a `PriceFormatter` to behave for real and you do not need to verify calls on it, just pass `new PriceFormatter()`. A spy adds instrumentation, cost, and a way for the test to get subtly wrong. ## Stubbing a spy is different The critical practical rule: because the real method runs, the usual `when(spy.method()).thenReturn(x)` form actually **invokes** `spy.method()` while you are setting up the stub. On `spy(new ArrayList<String>())`, writing `when(spied.get(0)).thenReturn("a")` throws `IndexOutOfBoundsException` from the real `get`. Use the `do*` family instead: ```java doReturn("a").when(spied).get(0); ``` That form never calls the real method. ## Other differences worth knowing - **Constructors.** `mock()` creates the instance without running any constructor; `spy(obj)` requires you to have built a real object first (or, with `@Spy` on an uninitialized field, lets Mockito call a no-arg constructor). - **The original is untouched.** `spy(list)` does not wrap `list`; it produces a separate instrumented instance with the fields copied across. Mutating the spy does not mutate the object you passed in. - **Argument capture and verification** behave identically on both. - **Strictness.** Mockito's strict stubbing flags unused stubs on both; a spy simply has fewer stubs to begin with. ## The mental one-liner A mock is a hollow shell that remembers what you asked it. A spy is the real object wearing a wire — it does its job, and it also reports everything it was asked to do.