asmhatre/JUnit_Tutorials
1
0
Fork 0
Code Activity

Add organising module: DisplayNameGenerator/@Nested/@Tag demos on JUnit 6.1.3

Browse Source 
Companion code for the rewritten post "Organising and Displaying JUnit Tests:
@DisplayName, @Nested, @Tag (JUnit 5 -> JUnit 6)". Same suite also runs green
on JUnit 5.14.4 via -Djunit.version. Verified, not assumed: GA dates and
versions cross-checked against Maven Central metadata and docs.junit.org
release notes; the @TestMethodOrder-inheritance-into-@Nested-classes and
MethodOrderer.Default/ClassOrderer.Default behaviour differences between
5.14.4 and 6.1.3 are demonstrated by actually running the same source under
both engines (see organising/output/12-* and 14-*), not by reading about them.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01YXCrLgRKFgCh9RHKW8xaqJ
This commit is contained in:
asmhatre
2026-10-01 04:38:28 +00:00
co-authored by Claude Sonnet 5
parent cfc6c79fc3
commit bfc67986bc
43 changed files with 1124 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
organising/README.md
+59
View File
@@ -0,0 +1,59 @@
# Organising and Displaying JUnit Tests - DisplayNameGenerator, @Nested, @Tag
Runnable companion to the ankurm.com article "Organising and Displaying JUnit Tests: @DisplayName,
@Nested, @Tag (JUnit 5 to JUnit 6)". Every scenario is a small fixture driven through the real
JUnit Platform Launcher (see `RunHelper.java`); the tests assert on what actually happened and
write it to `output/`, so every transcript quoted in the article is also an assertion that fails
the build the day it stops being true.
## Versions
| Item | Version |
|------|---------|
| JUnit (default, `junit.version`) | 6.1.3 (Jupiter, Platform, Launcher - single version line since 6.0) |
| Also run green on | 5.14.4 (`mvn test -Djunit.version=5.14.4`) |
| JUnit 6.0.0 GA date | September 30, 2025 (confirmed on `docs.junit.org/current/release-notes`) |
| Java | 17 language level (`maven.compiler.release`), run on JDK 25.0.4.1 (Temurin, current LTS) |
| Maven Surefire | 3.5.4 |
Both GA numbers were cross-checked against `maven-metadata.xml` on Maven Central
(`org/junit/platform/junit-platform-commons` and `org/junit/junit-bom`), not against a blog or an
LLM's memory - see the article's versions callout.
## What each scenario demonstrates
| Class | Shows | Output |
|-------|-------|--------|
| `DisplayNameFixtures.PlainDefault` | the default `Standard` generator - raw method signature | `01-default-generator.txt` |
| `DisplayNameFixtures.Underscored` | `DisplayNameGenerator.ReplaceUnderscores` | `02-replace-underscores.txt` |
| `DisplayNameFixtures.Sentences` | `DisplayNameGenerator.IndicativeSentences` joining class + nested + method into one sentence | `03-indicative-sentences.txt` |
| `DisplayNameFixtures.CustomSentenceCase` + `SentenceCaseGenerator` | a hand-written `DisplayNameGenerator` | `04-custom-generator.txt` |
| `DisplayNameFixtures.ConfiguredByDefault` | setting the generator project-wide via `junit.jupiter.displayname.generator.default`, no annotation touched | `05-no-config-param.txt`, `06-configured-default-generator.txt` |
| `LoanDeskTest` | `@DisplayNameGeneration` + `@Nested` + `@Tag` used together, tag inheritance into nested and doubly-nested classes | real `mvn test` run, `17-mvn-cli-tag-filter.txt` |
| `TagFixtures.CatalogServiceTest` | include/exclude filtering, composed tag annotations, OR-vs-AND semantics of `TagFilter.includeTags` | `07`, `08`, `09`, `09b` |
| `TagFixtures.TrimmedTagClass` | leading/trailing whitespace in a tag is silently trimmed, not invalid | `10`, `10b` |
| `TagFixtures.InternalWhitespaceTagClass` | internal whitespace **is** invalid - logged as a non-critical discovery warning and the tag is dropped, test still runs | `10c`, `10d` |
| `TagFixtures.BlankTagClass` | an empty `@Tag("")` inside `@Tags` is dropped the same way | `11` |
| `OrderingFixtures.DefaultSiblingOrder` | sibling `@Nested` class order with no orderer declared - deterministic, but a **different** order on 5.14.4 vs 6.1.3 | `12-*-run1/2/3.txt` (stability within a version), `12-*-junit5.14.4.txt` (cross-version diff) |
| `OrderingFixtures.ClassOrderOuter` | `@TestClassOrder` reaching two levels of `@Nested` nesting - identical on both versions in this repo's testing | `13-class-order-two-levels.txt` |
| `OrderingFixtures.MethodOrderInheritanceOuter` | `@TestMethodOrder` on an outer class now cascading into an unannotated `@Nested` child - **new in JUnit 6.0**, confirmed by a different real method order on 5.14.4 | `14-method-order-inheritance*.txt` |
| `src/broken/MethodOrdererDefaultDemo.java` | `MethodOrderer.Default` / `ClassOrderer.Default` (opt a `@Nested` class back out of inherited ordering) added in 6.0 - compiles on 6.1.3, fails on 5.14.4 | `15`, `16` |
## Prerequisites
- JDK 17 or higher (built and run here on JDK 25.0.4.1)
- Maven 3.6+
## How to run
```bash
mvn test # full suite, JUnit 6.1.3
mvn test -Djunit.version=5.14.4 # same suite, JUnit 5.14.4
mvn test -Dgroups=fast # only @Tag("fast") tests
mvn test -DexcludedGroups=slow # everything except @Tag("slow")
```
`scripts/run-all.sh` regenerates every file in `output/` from a clean state in one command,
including the cross-version comparison files and the `src/broken` compiler-message transcripts.
Instance ordering in `12-nested-sibling-order-*.txt` is stable within one JUnit version but is
explicitly NOT something to hand-derive - it is only ever read from a real run.