How does Mockito create the object when you annotate a test-class field with @Spy, and what kinds of classes or methods will that fail on?

## Two ways the field gets its value **You supply the instance.** ```java @Spy PriceFormatter formatter = new PriceFormatter(Locale.UK); ``` Mockito sees the field already initialized and spies that object — equivalent to `spy(new PriceFormatter(Locale.UK))`. This is the form to prefer whenever the object needs constructor arguments, needs to start in a particular state, or is expensive enough that you want to control its construction explicitly. It is also more readable: the reader sees what is being spied. **Mockito supplies the instance.** ```java @Spy PriceFormatter formatter; ``` With the field null, Mockito instantiates the declared type by locating a **no-arg constructor** and invoking it reflectively. Visibility is not a barrier — a `private` no-arg constructor works. For a non-static inner class, Mockito uses the enclosing test instance as the outer object. If no no-arg constructor is available, annotation processing throws with a message asking you to provide the instance yourself; that error is the direct cue to switch to the inline form. Either way the outcome is a spy, so unstubbed calls run real code, stubbed calls do not, and every call is recorded for `verify()`. ## What it cannot instantiate - **Interfaces.** There is nothing to instantiate and no real behaviour to run. If you want default methods exercised, spy a concrete implementation or use `mock(Iface.class, CALLS_REAL_METHODS)` for a targeted case. - **Abstract classes** with no supplied instance, for the same reason. (`mock(Abstract.class, CALLS_REAL_METHODS)` is the usual workaround when you need the concrete methods of an abstract base.) - **Types with only argument-taking constructors.** Initialize inline. - **Types whose no-arg constructor throws or does heavy work.** It will run for real during setup — a good reason to prefer the explicit form. ## What it cannot intercept Regardless of how the instance was obtained, some methods are outside Mockito's reach: - **`private` methods** — never overridable, never intercepted, in any Mockito version. Calls to them go straight to the real code. - **`static` methods** — need `Mockito.mockStatic(...)` in a try-with-resources scope; a spy has no effect on them. - **`final` methods and `final` classes** — this one is version-dependent. Mockito 2 through 4 defaulted to the subclass (Byte Buddy) mock maker, which physically cannot override `final`, so a final class could not be spied at all and a stub on a final method was silently ignored: the real method ran, and the test failed for reasons that looked impossible. Mockito 5 switched the default to the **inline mock maker**, which instruments loaded classes via a Java agent and can handle final classes and methods. If you are on an older version, `mockito-inline` as a dependency gives you the same capability. A related consequence: because a spy is an instrumented instance created without running a constructor and then field-copied, `equals` and `hashCode` are not intercepted by Mockito either — Mockito needs them for its own bookkeeping. Do not attempt to stub them. ## Interaction with @InjectMocks `@Spy` fields participate in injection exactly like `@Mock` fields: they sit in the same candidate pool and are matched by type, then by field name. So a spied collaborator can be handed to the object under test without any extra wiring. Stacking `@Spy` on the *same* field as `@InjectMocks` is a different feature — it wires the object under test and then wraps it as a partial mock. ## Nothing runs without annotation processing `@Spy`, like every Mockito annotation, is inert metadata. Use `@ExtendWith(MockitoExtension.class)` on JUnit 5, `MockitoAnnotations.openMocks(this)` in a `@BeforeEach` (closing the returned `AutoCloseable` afterwards), or the JUnit 4 runner/rule. Without one, the field is whatever your initializer left there — a **plain, uninstrumented object** if you initialized it inline, which is the nastiest variant of the mistake: the test runs, real behaviour happens, and `verify()` then fails with `NotAMockException` from a line that looks correct. ## Practical defaults - Initialize inline whenever construction is not trivially no-arg; it removes a class of setup failures and reads better. - Do not spy interfaces — spy the implementation. - On Mockito 5, final is no longer an obstacle; on older versions, check the mock maker before blaming your test. - Keep spies rare. `@Spy` on a collaborator you neither stub nor verify should just be a plain field holding a real object.