You need a Mockito ArgumentCaptor for an argument of type List<String>. Explain the problem with ArgumentCaptor.forClass and what the alternatives are.

## The root cause: erasure `ArgumentCaptor.forClass` has the signature `static <U,S extends U> ArgumentCaptor<U> forClass(Class<S> clazz)`. It needs a runtime `Class` token, and Java provides class literals only for raw types: `List.class` exists, `List<String>.class` does not. So a captor for a parameterised type cannot be expressed through `forClass` without losing the type argument. What people write: ```java @SuppressWarnings("unchecked") ArgumentCaptor<List<String>> captor = ArgumentCaptor.forClass((Class<List<String>>)(Class<?>) List.class); ``` It works, but it is noise, and the suppression hides a real (if harmless here) unchecked operation. ## Option 1: the @Captor annotation ```java @ExtendWith(MockitoExtension.class) class ImporterTest { @Mock Repo repo; @Captor ArgumentCaptor<List<String>> captor; @Test void savesAllNames() { new Importer(repo).importAll(); verify(repo).saveAll(captor.capture()); assertThat(captor.getValue()).containsExactly("ann", "bob"); } } ``` Mockito reads the field's declared generic type via reflection on the field's `Type` (which survives erasure in the class file's signature attribute) and builds a correctly typed captor. No cast, no warning. Initialisation happens through `MockitoExtension` (JUnit 5), `MockitoAnnotations.openMocks(this)` in a `@BeforeEach`, or the older `MockitoJUnitRunner` on JUnit 4. Forgetting the initialisation leaves the field null and produces a `NullPointerException` on `capture()` - one of the most common Mockito setup mistakes. ## Option 2: ArgumentCaptor.captor() Mockito 5.7 added a factory that takes no class token and infers `T` from the assignment context: ```java ArgumentCaptor<List<String>> captor = ArgumentCaptor.captor(); ``` This keeps the captor local to the test method - useful when only one test needs it and a field would be dead weight elsewhere. It also has a varargs form for reified type arguments in some usages. On older versions the annotation remains the way. ## What the generic parameter does and does not buy It is **compile-time only**. `capture()` returns `T` so the argument type-checks at the call site, and `getValue()` returns `T` so no cast is needed when asserting. Nothing verifies at runtime that the captured list contains only `String`s: type arguments are erased, and Mockito's captor stores `Object`s internally. If production code passed a `List<Integer>` through a raw-typed path, capture would succeed and the failure would surface as a `ClassCastException` at the point you read an element. The same is true of the non-generic case in a subtler way: `forClass(Email.class)` does not enforce that the captured argument is an `Email` at capture time either - `capture()` matches any value, including `null`. If the mocked parameter type is `Object`, a captor declared for `Email` will happily capture something else and throw on read. ## Related typing gotchas **Varargs.** Capturing a varargs parameter is special: declare the captor for the component type (`ArgumentCaptor<String>` for a `String...` parameter) and `getAllValues()` returns the individual elements. Mixing this up with an array-typed captor is a frequent surprise. **Primitives.** `ArgumentCaptor.forClass(int.class)` is not what you want; use `Integer.class`, since Mockito stores boxed values. **Nulls.** `getValue()` can legitimately return `null` if the code passed `null`; that is distinct from "nothing captured", which throws a `MockitoException`. ## Interview framing The grader wants: erasure explains why `forClass` cannot express `List<String>`; `@Captor` reads the field's generic signature and is the idiomatic answer; `ArgumentCaptor.captor()` is the modern local-variable alternative; and the type parameter is compile-time convenience, not a runtime guarantee.