Add parameterized module: JUnit 5 @ParameterizedTest argument sources, display names, and two real anti-pattern failures

2026-10-03 21:50:52 +00:00
parent 8be1245951
commit ee75bfa792
45 changed files with 1179 additions and 0 deletions
@@ -0,0 +1,31 @@
+Captured from a real `junit-platform-console-standalone --details=tree` run against
+MixedAssertionsAntiPatternTest, compiled and executed for real.
+
+╷
+├─ JUnit Platform Suite ✔
+├─ JUnit Jupiter ✔
+│  └─ MixedAssertionsAntiPatternTest ✔
+│     ├─ adminShouldDelete(Role) ✔
+│     │  └─ [1] ADMIN ✔
+│     ├─ testPermissions(String, boolean, boolean) ✔
+│     │  ├─ [1] "ADMIN", "true", "true" ✔
+│     │  └─ [2] "GUEST", "false", "true" ✔
+│     └─ allRolesShouldRead(Role) ✔
+│        ├─ [1] ADMIN ✔
+│        ├─ [2] SUPERUSER ✔
+│        ├─ [3] EDITOR ✔
+│        ├─ [4] USER ✔
+│        └─ [5] GUEST ✔
+└─ JUnit Vintage ✔
+
+Test run finished after 246 ms
+[         8 tests successful      ]
+[         0 tests failed          ]
+
+testPermissions is the BAD example: one parameterized test asserting two unrelated behaviors
+(canDelete and canRead) per row, so a failure in either one just says "testPermissions failed"
+without telling you which behavior broke. It passes here -- this is a design-smell illustration,
+not a test that's expected to fail -- but a reader who only sees it pass has no way to tell
+canDelete and canRead apart from the test name alone. adminShouldDelete and allRolesShouldRead
+are the fix: the same two behaviors, split into two single-assertion parameterized tests, each
+with a display name that says exactly what broke if it ever does.