You switched a large JUnit 5 suite to concurrent execution and a handful of tests started failing intermittently. How do you diagnose the failures and roll the change out safely?

## Why concurrency exposes bugs that were always there A sequential suite grants every test an accidental guarantee: nothing else is running. Under `@Execution(CONCURRENT)` or a `concurrent` default mode that guarantee disappears, and any state shared between two tests becomes a race. The tests were latently broken; parallelism made them observable. Framing it that way matters in an interview, because the wrong instinct — "parallel execution is flaky, turn it off" — is exactly the answer that fails the question. ## Step 1 — attribute the failure Rerun the same commit with the master switch off (`junit.jupiter.execution.parallel.enabled=false`, easiest as a JVM system property so you change nothing in the repository). If it is green sequentially and intermittently red concurrently, concurrency is the trigger. If it is flaky both ways, you have an ordinary flaky test (time, randomness, external service) and parallelism is a red herring. ## Step 2 — narrow with execution mode, not with luck Execution mode is your bisect tool, and it works at two granularities: - Set `junit.jupiter.execution.parallel.mode.classes.default=concurrent` with `junit.jupiter.execution.parallel.mode.default=same_thread`. Now the class is the unit of concurrency and everything a class privately owns is single-threaded again. Failures that disappear here were caused by two methods of the same class colliding — usually a `static` field, a `@TestInstance(PER_CLASS)` instance field, or a `ThreadLocal` populated in `@BeforeEach` and read on another thread. - Failures that survive are cross-class: JVM-global or environment-global state. Then bisect further by annotating individual classes `@Execution(SAME_THREAD)` and seeing which annotation makes the failure disappear. That identifies the culprit far faster than reading code. ## Step 3 — make the race reproducible Random interleavings are hard to debug. Pin the pool with `config.strategy=fixed` and `config.fixed.parallelism=2`: with two threads there are few possible interleavings and the failure often becomes near-deterministic. Then run just the two suspect classes together in a loop. Logging `Thread.currentThread().getName()` in the setup and teardown of the suspects gives you a cheap interleaving trace when the failure is rare. ## Step 4 — the usual culprits In order of how often they turn up: 1. **`static` mutable fields** — caches, counters, a lazily-built singleton, a shared `SimpleDateFormat`. 2. **JVM-global settings** — `System.setProperty`, `Locale.setDefault`, `TimeZone.setDefault`, redirected `System.out`. One test's setup silently reconfigures another test that is already running. 3. **Fixed external coordinates** — a hardcoded port, a fixed file path in the system temp directory, a fixed record id in a shared database. 4. **Shared containers or servers** started once for the suite and mutated per test. 5. **Order dependence** — test B only passed because test A ran first and populated something. Parallelism destroys the ordering assumption even before it creates a data race. 6. **Frameworks with global registries** — anything that installs a global default and restores it in teardown is a landmine when two tests overlap. ## Step 5 — fix at the right level The durable fix is to remove the sharing: give each test its own instance, its own temporary directory, an ephemeral port, a unique identifier prefix, its own database schema or a rolled-back transaction. Second best is to make the shared thing thread-safe or thread-confined. Only when neither is affordable do you serialise the test — pinning it to one thread with `@Execution(SAME_THREAD)` if the collision is between methods of one class, or declaring the shared thing as an exclusive resource when the collision is with other classes (that is a separate JUnit mechanism, and the right one when the state is genuinely global). Whatever you choose, record it: an `@Execution(SAME_THREAD)` with no comment becomes permanent, and permanent serialisation is why suites stop getting faster. ## Step 6 — roll out as a ratchet A safe rollout looks like this: - Enable the switch with defaults still `same_thread`, so nothing changes behaviourally and the configuration lands on its own. - Turn on class-level concurrency and fix the fallout. - Add a scheduled job that runs the suite several times in a row at a low fixed parallelism; races that appear once in twenty runs will not survive that. - Only then consider method-level concurrency, and expect a second, smaller wave of failures. Quarantining rather than fixing is acceptable for a day, not a quarter. Track the serialised classes as a list that must shrink, otherwise the suite converges back to sequential with extra annotations. ## Signals you should watch After the rollout, watch three numbers: wall-clock time (the reason you did this), the flake rate per run, and the count of `SAME_THREAD` annotations. If the second and third rise while the first barely moves, the parallelism is not paying for itself and you should either invest in test isolation or revert.