A team's JUnit 5 tests iterate over a Java enum but exclude two constants by name so the suite stays green. Six months later a new constant is added and nothing fails. What went wrong, and how would you set up enum-driven tests so a newly added constant cannot slip through untested?

## The failure mode Enums are closed sets, and tests over them are implicitly a claim about *the whole set*. The moment a test filters the set with `names`, that claim narrows — and nothing in the type system or the build records the narrowing. Six months later a constant is added by someone who never saw the test, and the suite is still green because no assertion depended on completeness. There are two distinct variants worth separating in the answer: 1. **`EXCLUDE` narrowing.** `@EnumSource(mode = EXCLUDE, names = {"LEGACY", "UNKNOWN"})` does include a newly added constant automatically. The silent-drift risk here is not exclusion but *weak assertions*: if the shared test only checks 'does not throw', a new constant with no mapping and a default `else` branch passes. Exclusion also rots — the excluded names were excluded for a reason nobody wrote down, and by the time the reason is gone the exclusion stays. 2. **`INCLUDE` narrowing.** `@EnumSource(names = {"OPEN", "CLOSED"})` is worse: a new constant is never exercised at all. INCLUDE lists are how enum tests quietly freeze at the state of the enum on the day they were written. A third, sharper variant: `MATCH_ALL`/`MATCH_ANY` regex modes. These select by pattern against `name()` and are validated against nothing. A rename that breaks the pattern, or a new constant that does not match the naming convention, changes coverage without any signal. By contrast, `INCLUDE`/`EXCLUDE` names *are* validated against the enum's declared constants, so a rename fails the build with a configuration error — a small but real safety property, and the main reason to prefer literal modes for small sets. ## Designing for exhaustiveness The goal is that adding a constant produces a failure somewhere. Three complementary techniques: **1. One unfiltered contract test.** Keep at least one `@EnumSource` with no `names`, asserting the invariant that must hold for every constant: ```java @ParameterizedTest @EnumSource void everyStatusHasAHandler(Status status) { assertNotNull(registry.handlerFor(status), "no handler registered for " + status); } ``` This is the single highest-value enum test in most codebases: it converts 'someone forgot to extend the switch' from a production NPE into a red build. The assertion must be strong enough to actually fail for an unhandled constant — which usually means the production code should *throw* on an unknown constant rather than fall through a permissive `default`. **2. Data that pairs constant with expectation.** When each constant has a different expected result, do not put a `switch` in the test body — that just re-implements the production mapping and can drift in the same direction. Supply pairs from a source that yields argument tuples, and assert that the set of pairs covers the enum (`assertEquals(Status.values().length, cases.size())` in a companion test). **3. Filters carry a reason and an expiry.** If a constant genuinely must be excluded, record why in the test's display name or a comment, and prefer excluding the *behaviour* (a separate test asserting the exception path for that constant) over excluding the case entirely. An excluded constant with no test anywhere is the actual defect. ## Judgement, not dogma Exhaustive enum tests are not free. Over a large enum they multiply invocation counts and can encourage weak assertions purely to keep the shared test green — precisely the failure this question is about. The useful line: exhaustive over *invariants* (every constant maps to something, serialises, has a label), explicit and non-exhaustive over *behaviours* (this constant transitions to that state). And 'the enum grew and no test noticed' is a review-time smell worth naming, not just a runtime one. ## How to answer Diagnose first — the exclusion is a symptom; the missing exhaustive assertion is the cause. Then give the concrete setup: one unfiltered contract test with an assertion strong enough to fail, literal `INCLUDE`/`EXCLUDE` over regex so renames are loud, and expectations carried in the data rather than a `switch` in the test.