A JUnit 5 argument source built from annotation literals cannot supply null, yet null, empty string and blank string are exactly the inputs a validation method must reject. How do you cover all three in one parameterized test?

## Why the dedicated sources exist Java annotations cannot hold `null` as an array element, so a literal source can never express the null case — and `null`, `""` and `" "` are the three inputs most validation bugs actually live in. JUnit therefore ships three small sources that fill precisely that gap. - **`@NullSource`** provides exactly one argument set consisting of a single `null`. - **`@EmptySource`** provides one argument set holding the empty value for the parameter's declared type: `""` for `String`, an empty `List`, `Set` or `Map`, an empty array (primitive or object), and, in more recent JUnit 5 versions, empty instances for a wider set of collection types. - **`@NullAndEmptySource`** is a composed annotation that simply carries both of the above. None takes any attributes; the parameter's type is what decides the value. ## Repeatability is the whole trick JUnit's `@ArgumentsSource`-based annotations are repeatable on a test method. The engine collects every source in declaration order and concatenates their argument sets into one stream of invocations. That is why a validation test can read as a stack of sources: ```java @ParameterizedTest @NullAndEmptySource // null, "" @ValueSource(strings = {" ", "\t"}) // blanks void rejectsBlank(String candidate) { } // 4 invocations ``` Declaration order determines invocation order and therefore the `{index}` values in the report — worth knowing when reading a failure line, not something to depend on. ## Constraints and failure modes **Single argument only.** All three sources supply one value per invocation, so the test method must take one parameter (plus any injected ones such as `TestInfo`). Combining them with a multi-argument source in the same method is a mismatch: the null/empty sources will supply one value to a method expecting two, and the invocation fails to resolve. **Primitives reject null.** `@NullSource` on an `int` parameter cannot work — there is no null `int`. JUnit fails that invocation with a parameter-resolution error. If a null case is meaningful, the parameter must be `Integer`. This is the single most common surprise with these annotations. **`@EmptySource` needs a supported type.** If the parameter type has no defined empty instance (say a domain object, or `Optional`), `@EmptySource` fails with a configuration error rather than inventing something. It is deliberately conservative. **Null-hostile call sites.** A worthwhile note for Kotlin-adjacent or annotated codebases: if the method under test declares a non-nullable parameter enforced at runtime, the null case asserts the enforcement mechanism rather than your validation logic. Decide which behaviour the test is about. ## Why interviewers like this one It is a small mechanism, but the answer reveals whether someone writes edge-case tests at all. Null, empty and blank are the canonical boundary trio for any string input, and the fact that JUnit shipped first-class sources for them is a hint about how often they matter. A candidate who reaches for `@NullAndEmptySource` plus a whitespace `@ValueSource` has written real validation tests; one who proposes a separate `@Test` for null is not wrong, just less fluent — and loses the shared assertion. A reasonable follow-on judgement: keep these cases in the *same* test only while the expected behaviour is identical for all of them. If `null` throws `NullPointerException` while `""` throws `IllegalArgumentException`, forcing them into one parameterized method means asserting a supertype or branching in the body — both of which weaken the test. Split instead. ## How to answer Name all three annotations, state that source annotations are repeatable and concatenate, show the stacked declaration, and volunteer the primitive-parameter caveat. That last detail is the one most candidates learn only by hitting the error.