When standardizing test naming across a large codebase, how would you decide between explicit @DisplayName, a DisplayNameGenerator default, and method-name conventions?
answer
- Choose ONE enforceable convention at scale
- Generator default via junit-platform.properties for the 95%
- Explicit @DisplayName as override (it always wins)
- Align checkstyle/IDE with underscore vs camelCase
- Verify CI/report rendering; document in CONTRIBUTING
basics
~20 sPick one default strategy for the whole codebase (often a generator like ReplaceUnderscores set via the config property), allow explicit @DisplayName to override where wording matters, and enforce it so reports stay consistent and low-maintenance.
solid answer
~40 sAt scale, naming consistency and low maintenance matter more than any single test's wording. I'd set a project-wide default — usually junit.jupiter.displayname.generator.default pointing at ReplaceUnderscores or IndicativeSentences — so most names derive automatically from intention-revealing method names, costing nothing per test. I'd reserve explicit @DisplayName for cases the generator reads awkwardly (special characters, domain phrasing) since it always overrides. I'd weigh trade-offs: underscore method names can fight checkstyle/IDE conventions, so the team aligns lint rules; sentence generators read like specs but bloat with deep @Nested nesting. I'd codify the choice in a contributing guide and enforce via shared junit-platform.properties and CI lint. The goal is uniform, self-documenting reports that survive refactors — not bespoke names that drift. I'd also confirm CI/report tooling renders the chosen names well, since the whole point is readable failures.
go deeper
Can apply @DisplayName but isn't expected to set codebase-wide policy.
Knows the default-generator property exists and that explicit names override it.
Selects and configures a suite-wide generator, reserves @DisplayName for exceptions, and reasons about lint/report trade-offs.
Owns the naming convention as governance: enforces it via shared config and CI, aligns lint tooling, weighs migration cost and report/CI readability, and documents it.
## Framing: this is a governance decision, not a syntax one The mechanics (`@DisplayName`, `DisplayNameGenerator`, the default config property) are simple; the principal-level question is choosing a **single, enforceable convention** that keeps thousands of tests readable and cheap to maintain. The options: ### Option A — explicit `@DisplayName` everywhere - **Pros:** maximum control over wording; special characters/domain language at will. - **Cons:** boilerplate on every method; easy to forget or let drift; the name and the method can disagree, creating two sources of truth. ### Option B — a `DisplayNameGenerator` default Set once via `junit.jupiter.displayname.generator.default` in a shared `junit-platform.properties`: - **`ReplaceUnderscores`** — write intent in the method name (`rejects_a_negative_total`), get `"rejects a negative total"` for free. - **`IndicativeSentences`** — `@Nested` context + method become a spec-style sentence. - **Pros:** zero per-test boilerplate; one source of truth (the method name); uniform. - **Cons:** underscore-style names can clash with checkstyle/IDE camelCase rules; sentence style bloats with deep nesting; less control over awkward phrasings. ### Option C — method-name conventions alone (no annotations) Rely on `Standard`/`Simple` and disciplined camelCase like `shouldRejectNegativeTotal`. - **Pros:** no extra config; familiar. - **Cons:** least readable in reports; camelCase doesn't render as prose. ## The pragmatic answer: B with A as an override Because **explicit `@DisplayName` always overrides a generator**, you don't have to pick exclusively. Set a generator default (B) for the 95% case and use `@DisplayName` (A) only where the generated name reads poorly. This gives uniformity *and* an escape hatch. ## Cross-cutting concerns a principal weighs 1. **Lint alignment.** If you adopt underscore method names, update checkstyle/IDE inspections so they don't fight the convention. 2. **Tooling/report rendering.** Confirm the IDE, Gradle/Maven console, and CI/HTML report show the chosen names well — the entire value is readable failures in CI. 3. **Refactor resilience.** Generator-derived names track the method automatically; explicit names can drift after a rename. Fewer hand-written names = fewer stale labels. 4. **Onboarding & discoverability.** A documented convention in CONTRIBUTING plus a shared `junit-platform.properties` makes the rule discoverable and enforceable, not tribal knowledge. 5. **Internationalization/characters.** If domain names need symbols or non-ASCII, explicit `@DisplayName` is the only clean route. 6. **Migration cost.** Switching an existing suite is mostly free with a generator default (no per-file edits); converting to explicit names everywhere is a large, error-prone change. ## What "good" looks like A single property in a shared config selects the generator; method names are intention-revealing; a small, documented set of `@DisplayName` overrides handles exceptions; lint rules and CI enforce it; and a CI failure line reads as a sentence describing the broken behavior. Key terms: **`junit-platform.properties`** is a file on the test classpath holding JUnit config keys; a **config default** applies unless an annotation overrides it; **governance** here means a team-wide, enforced convention.
- How do you apply one naming strategy across all test classes without touching each file?Set junit.jupiter.displayname.generator.default to the generator's FQN in a shared junit-platform.properties on the test classpath.
- If most names are generated, how do you handle the few that read awkwardly?Add an explicit @DisplayName on those elements; it overrides the generator just for them.
- What non-JUnit concern often breaks an underscore-based naming convention?Checkstyle/IDE method-name inspections that enforce camelCase; align or suppress those rules.
saying these in an interview costs you the question
- Treating it as a per-developer style choice instead of a governed convention
- Forgetting explicit @DisplayName overrides the generator (so B and A combine)
- Ignoring checkstyle/IDE friction from underscore method names
- Assuming switching strategies later is cheap for explicit-name-everywhere suites