How do you decide the degree of parallelism for a JUnit 5 test suite, and how do you judge whether running tests concurrently is paying off at all?

## Framing: this is capacity planning, not a config value The question has no single right answer, which is the point. Choosing parallelism means trading three things against each other: wall-clock feedback time, the reliability of the signal, and the engineering effort required to make tests independent enough to overlap. A good answer talks about all three and about how you would *measure*, rather than naming a number. ## Step 1 — characterise the workload Different suites have different ceilings: - **CPU-bound pure unit tests.** Every thread is genuinely computing. Throughput peaks near one runnable thread per core; beyond that you pay context switching and cache pressure for nothing. `dynamic` with factor 1.0. - **I/O-bound tests** — HTTP calls to a stub, database round-trips, container start-up, deliberate waits. Threads are idle most of their life, so parallelism well above the core count helps: factors of 2–4 are common. The ceiling is no longer the CPU but the far side: the stub server's own thread pool, a JDBC connection pool, the database's max connections. - **Memory-heavy tests** — each concurrent test may hold a Spring context, a container client or a large fixture. Here the binding constraint is heap, and the honest limit is whatever keeps you clear of GC thrash and out-of-memory failures. This is the case people forget: doubling threads can double peak heap. - **Suites dominated by one long test or one long class.** Amdahl's law applies bluntly — if one class takes 8 minutes of a 10-minute suite, no thread count gets you below 8 minutes. The fix is splitting that class, not more threads. ## Step 2 — pick the mechanism to match the environment `dynamic` derives parallelism from `availableProcessors()`. That is right on a developer machine, where you may even want a factor below 1.0 so the IDE stays responsive. On CI it is often wrong: shared executors and containers can report far more processors than your job is actually allowed to use, and the resulting over-subscription produces runs that are slower *and* flakier than sequential. `fixed` with an explicit number, chosen per executor class, is the reproducible choice — and reproducibility matters independently, because a race that only appears at parallelism 8 should appear identically on every machine. When the number must be derived at runtime — a shard count, a provisioned schema count, an environment variable set by the CI system — a `custom` strategy class keeps that logic in one place instead of scattering it through build configuration. ## Step 3 — measure the right things Sweep the parallelism value (1, 2, 4, 8, 16) and record, for each: 1. **Total wall-clock time** — the reason for the exercise. 2. **Flake rate over repeated runs** — run the suite five or ten times per setting. A configuration that is 40% faster and 5% flaky is worse than one that is 30% faster and stable, because a flaky suite is a suite people stop trusting and start rerunning. 3. **Peak memory / GC time** — the silent limit. 4. **The tail** — the slowest class or method. If the tail dominates, further threads are wasted. 5. **Contention on external systems** — connection-pool wait time, container CPU throttling, database lock waits. The shape you expect is a curve that improves steeply, then flattens, then degrades. Choose a point on the flat part, slightly conservative, not the exact minimum — the minimum is the most fragile setting. ## Step 4 — count the costs people forget - **Isolation work.** Every test that shares global state must be fixed or serialised. That is engineering time and it competes with product work. If the suite is 4 minutes, spending three weeks to make it 2 minutes is a bad trade; if it is 40 minutes and blocks every merge, it is an excellent one. - **Debuggability.** Interleaved output and stack traces from several tests at once make failures harder to read. Teams often keep a sequential mode available for local debugging. - **Serialisation debt.** Each class pinned to a single thread or guarded by an exclusive resource is a permanent brake. A suite where half the classes are serialised has the complexity of parallelism and the speed of sequential — that is the state to detect and either finish or abandon. - **Alternative levers.** Parallelism inside one JVM is not the only tool: splitting the suite across CI machines, running slow and fast tiers separately, and simply deleting redundant tests can beat it. A principal-level answer names these rather than assuming thread count is the only dial. ## Step 5 — decide and revisit Commit a default in the shared configuration, allow per-environment overrides through system properties, and record the reasoning where the next person will read it. Revisit when the suite's shape changes — a new integration tier, a move to different CI hardware, a jump in memory per test. The number is not a constant; it is a function of the suite and the machine, and it should be re-measured rather than inherited.