Lesson 04 · Parallelism, Flakiness & Reporting

Beyond the 1Z0-830 exam

The last architecture concern is running the suite: making it fast with parallelism, keeping it trustworthy by eliminating flakiness, and surfacing results through reports. A fast suite nobody trusts is worthless.

Objectives

After this lesson you will be able to:

• Enable and reason about parallel test execution in JUnit 5.
• Diagnose and fix flaky tests (and why blanket retries are a trap).
• Produce and read reports (Surefire, Allure).

Parallel execution

JUnit 5 can run tests concurrently — enabled via junit-platform.properties:

junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent

Speedup is real, but only safe if tests are isolated. Control it where needed:

• @Execution(ExecutionMode.SAME_THREAD) forces a class/method to run serially.
• @ResourceLock("db") serializes tests that touch a shared resource, while the rest run concurrently.

Gotcha

Parallelism doesn't cause flakiness — it exposes latent shared-state bugs that were hidden by serial ordering. A test that fails only under parallel execution has a real isolation problem (static fields, shared files, a singleton, default time zone), not a "parallelism problem."

Flaky tests — find the cause, don't paper over it

A flaky test passes and fails without code changes. The usual culprits:

Cause	Fix
Shared mutable state / order dependence	isolate; reset in teardown; immutable fixtures
Time / time zone (Instant.now())	inject a Clock (Module 14 L04)
Unseeded randomness	seed the RNG
Async waited on with sleep	wait on a condition (latch/Future/Awaitility)
Real network/3rd-party calls	stub them (WireMock — Module 17)
Test execution order assumptions	make each test self-contained

Trap — retry-until-green

Configuring CI to auto-retry failed tests until they pass hides real intermittent bugs — a race condition that fails 1-in-20 will ship, because the retry "fixed" it. Instead: quarantine the flaky test (tag it, exclude from the gate, file a ticket) and fix the root cause. A retry policy is a diagnosis aid, never a permanent solution. Treat a flaky test as a bug in the test or the code — never as noise to mute.

Reporting

Report	What it is
Surefire	Maven's built-in XML/text reports in target/surefire-reports/ — the CI default, machine-readable
JUnit XML	the universal format CI systems parse to show pass/fail trends
Allure	a rich HTML report: steps, attachments (screenshots/logs), history, flakiness trends

@DisplayName (Module 14) flows straight into these reports, so readable names pay off here: M15·L04 — Saturday is the weekend is a far better failure line than test3. Attach context (screenshots for UI tests, request/response for API tests) so a failure is diagnosable from the report, without rerunning locally.

SDET note

The whole point of reporting is fast triage: when CI is red, a good report tells you which behaviour broke and why in seconds. This connects directly to Module 20 (CI/CD), where these reports become build artifacts published on every run, and to test selection — fast unit reports gate every push, fuller reports run nightly.

Key Takeaways

• JUnit 5 parallelism is opt-in (junit-platform.properties) and safe only for isolated tests; use @Execution(SAME_THREAD) / @ResourceLock to serialize where needed.
• Parallelism exposes shared-state bugs, it doesn't create them.
• Flaky = passes/fails with no code change; fix the root cause (time, randomness, async, shared state, network) — don't mask it.
• Retry-until-green hides real bugs; quarantine and diagnose instead.
• Use Surefire/JUnit XML for CI and Allure for rich, attachable reports; @DisplayName makes failures readable.

Lesson Quiz

Lesson Quiz · Parallelism, Flakiness & Reporting0 / 5

1. A test fails only when the suite runs in parallel. What does that indicate?

   • AA bug in JUnit's parallel engine
   • BA latent isolation problem (shared mutable state) that serial ordering was hiding
   • CThe test is too fast
   • DParallelism should never be used

2. What is a flaky test?

   • AA slow test
   • BA test that passes and fails without any code change
   • CA test with no assertions
   • DA parameterized test

3. Why is a blanket 'retry failed tests until they pass' policy dangerous?

   • AIt's slower
   • BIt can mask genuine intermittent bugs (e.g. race conditions), letting them ship
   • CIt breaks the compiler
   • DIt disables reporting

4. How do you let most tests run concurrently but serialize the few that share a database?

   • ADisable parallelism entirely
   • BAnnotate the DB-touching tests with @ResourceLock so they don't run concurrently with each other
   • CAdd Thread.sleep
   • DRun them in a separate JVM only

5. What does Allure add over plain Surefire XML?

   • ANothing
   • BRich HTML reports with steps, attachments (screenshots/logs), and history/flakiness trends
   • CFaster test execution
   • DMocking support

---

Next: Module 16 · Working with Databases. This module's lab is in labs/src/main/java/com/jse21/m15_architecture/.