You need a JUnit 5 test to run once per constant of a Java enum, and later to run over only a named subset of those constants. How do you declare that, and how do you express both 'only these' and 'all except these'?

## Running once per constant `@EnumSource` is the argument source for enums. In its simplest form: ```java enum Status { OPEN, IN_REVIEW, CLOSED, ARCHIVED } @ParameterizedTest @EnumSource void everyStatusIsHandled(Status status) { assertDoesNotThrow(() -> handler.handle(status)); } ``` The engine produces one invocation per declared constant, in declaration order, passing the constant itself. The enum type is taken from the annotation's `value` attribute if given (`@EnumSource(Status.class)`); since JUnit 5.6 it is inferred from the test method's single parameter when omitted. Being explicit is still common in codebases where the parameter is declared as a supertype or where readability matters more than brevity. ## Subsetting: names + mode Two attributes cooperate. `names` is a `String[]`; `mode` is a `Mode` enum that decides how those strings are interpreted: - **`INCLUDE`** — the default. Only constants whose names appear in the list are supplied. - **`EXCLUDE`** — every constant *except* the listed ones. - **`MATCH_ALL`** — names are regular expressions; a constant is selected only if it matches **all** of them. - **`MATCH_ANY`** — names are regular expressions; a constant is selected if it matches **at least one**. - **`MATCH_NONE`** (newer JUnit 5 versions) — the regex complement: constants matching none of the patterns. ```java @ParameterizedTest @EnumSource(mode = EXCLUDE, names = {"ARCHIVED"}) void liveStatusesAreEditable(Status status) { } @ParameterizedTest @EnumSource(mode = MATCH_ALL, names = "^IN_.*$") void intermediateStatuses(Status status) { } ``` Regex modes match against the constant's `name()`, and the whole name must match the pattern. ## The validation difference that matters With `INCLUDE` and `EXCLUDE`, JUnit validates the supplied names against the enum's actual constants. A name that does not exist — a typo, or a constant someone renamed — makes the test fail with a configuration error naming the bad entry. That is a genuinely useful property: refactoring the enum cannot silently detach the test from it. Regex modes give up that safety. Patterns are not validated against anything; they simply select whatever they select. If a rename turns `IN_REVIEW` into `UNDER_REVIEW`, a `^IN_.*` pattern quietly stops matching it. When nothing at all matches, the test produces zero invocations, which JUnit treats as an error by default (recent versions expose an `allowZeroInvocations` opt-out on `@ParameterizedTest`) — but partial silent narrowing is the real hazard, and it produces a green build with reduced coverage. So: prefer `INCLUDE`/`EXCLUDE` for small, explicit sets; reserve regex modes for enums with a genuine naming convention (`ERROR_*`, `*_DEPRECATED`) where the convention is itself the selection criterion. ## Reporting Invocation labels render the constant via `toString()`, so with default settings a run reads `[2] status=IN_REVIEW`. That readability is part of why `@EnumSource` is preferred over listing constant names as strings in a literal source: the argument is the real enum value, type-checked at compile time and renamed automatically by IDE refactoring, rather than a string that drifts. ## Where it fits `@EnumSource` covers the 'same behaviour for each constant' shape. As soon as each constant needs a *different* expected result, you are back to argument tuples and a different source — pairing a constant with its expectation is not something `@EnumSource` can express, and forcing it leads to a `switch` inside the test body, which is a test that asserts its own copy of the production mapping. ## How to answer Show the bare form, then `names` + the four modes, and volunteer the validation asymmetry between the literal modes and the regex modes. That last point is the one that distinguishes usage from understanding.