@ValueSource & @EnumSource

## The mechanism A plain `@Test` method runs once. `@ParameterizedTest` marks the method as a template: the Jupiter engine looks for one or more *argument source* annotations, asks each to produce a stream of argument sets, and runs the method once per set. Every run is an independent invocation with its own lifecycle — `@BeforeEach`/`@AfterEach` execute around each one — and its own entry in the report. `@ValueSource` is the simplest source: a single array of literals, each element becoming the sole argument of one invocation. ```java @ParameterizedTest @ValueSource(ints = {1, 2, 3}) void isPositive(int n) { assertTrue(n > 0); } ``` Three invocations, three report lines. Contrast the loop-inside-one-test alternative: a loop stops at the first failing element, hides the remaining cases, and reports one opaque failure. Parameterization keeps the cases independent — a real behavioural difference, not a style preference. ## What the annotation can carry `@ValueSource` declares one array attribute per supported type: `shorts`, `bytes`, `ints`, `longs`, `floats`, `doubles`, `chars`, `booleans`, `strings`, `classes`. That list is the whole menu, and it exists because Java annotations may only hold primitives, `String`, `Class`, enums, other annotations, and arrays of those. Exactly one attribute must be set. Setting `ints` and `strings` together is a configuration error, and so is setting none — JUnit fails the test rather than running zero invocations. (Newer JUnit 5 versions add an `allowZeroInvocations` opt-out on `@ParameterizedTest`, but the default remains: no arguments is a failure, because a silently empty test is worse than a red one.) Because annotation attributes are compile-time constants, everything dynamic is off the table: no `Instant.now()`, no values read from a file, no objects. A `static final` constant works; a computed field does not. ## Widening and conversion The declared array type does not have to match the parameter type exactly. JUnit applies widening primitive conversion, so `@ValueSource(ints = {1, 2})` can feed a `long` or `double` parameter. It also performs implicit conversion from `String` to many target types — `@ValueSource(strings = {"2024-05-01"})` can bind to a `LocalDate` parameter. Those conversion rules are their own subject; the point here is that `strings` is more flexible than it first looks and is often used to reach non-annotatable types. ## What it cannot do, and what to reach for instead Two cases break out of `@ValueSource` immediately: - **More than one argument per case** — e.g. input plus expected output. `@ValueSource` supplies exactly one value per invocation; you need a source that produces argument tuples. - **`null`, or values that must be constructed** — annotations cannot hold `null` or objects. `@NullSource`, `@EmptySource` and `@NullAndEmptySource` cover the null/empty edge cases declaratively; anything requiring construction needs a method- or provider-based source. A good instinct at review time: if a `@ValueSource` list has grown to twenty near-identical literals, or if the test body branches on the value (`if (input.equals("admin")) ...`), the parameterization has stopped being a table of cases and become a disguised loop with hidden conditionals. Cases should exercise the same behaviour with different data; different behaviours want different test methods. ## How to answer Show the two annotations, state 'one value per invocation', and list the three real constraints — single attribute, constants only, no null. Adding *why* it beats a loop (independent invocations, per-case reporting) is what separates a rehearsed answer from an understood one.