32 lines
1.4 KiB
Plaintext
32 lines
1.4 KiB
Plaintext
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.
|