xUnit 4.0.0 makes full test-case parallelization an explicit option.
That is useful, but xUnit 4 ParallelMode.All changes a quiet assumption in many suites: tests in the same class, including separate rows of one theory, may now overlap.
A static fake, shared fixture, temporary file, or database record that was safe under collection-level parallelism can become a race.
I treat this as an isolation change, not a speed switch.
Before enabling it across a suite, I want a deterministic failure that proves the risk and a deterministic check for each guardrail.
What xUnit 4 ParallelMode.All changes The xUnit.net v3 4.0.0 release notes describe full test-case parallelization as a new feature.
The default is still , so upgrading does not silently enable the broader mode.
I have to opt in at the assembly level: With , tests within a collection are serialized.
With , every test case is eligible to run beside every other test case.
That includes two cases from the same class and two pre-enumerated rows from the same theory.
The official parallel test execution guide documents the modes, algorithms, and available opt-out scopes.
I set in the sample so the scheduling condition is easy to inspect.
It is a demonstration setting, not a recommendation for CI.
The right value depends on available CPU, memory, and the external systems touched by the tests.
Before changing the mode, I scan for mutable fields, and implementations, fixed file names, environment-variable changes, test servers bound to fixed ports, and records addressed by shared IDs.
I also check theory data sources for objects that rows can mutate.
That inventory tells me whether the resource should become concurrency-safe, receive a unique per-test identity, or stay behind an explicit opt-out.
It is much easier to make that choice before a broad CI failure mixes several races together.
Reproduce a lost update without a stopwatch A timing-only test built around can pass for the wrong reason.
I prefer coordination primitives that force the interleaving I need to observe.
The unsafe sample runs two theory rows against one static counter.
Both rows read before either can write, and both finish writing before either asserts: Both rows observe , both write , and both assertions fail.
The barriers make the lost update repeatable; a busy machine does not have to get lucky with scheduling.
A timeout keeps a broken configuration from hanging forever.
This test is intentionally red.
I keep it in a separate project so the failure is evidence produced by the verifier, not a permanently failing test in the guarded suite.
Keep parallel tests safe and opt out narrowly If shared state is meant to support concurrent access, I make the operation atomic: That is appropriate for a counter, but a lock or concurrent collection may be a better fit for a compound invariant.
Thread safety also does not provide test isolation by itself.
Two tests can update a data structure correctly and still observe each other's logical data.
When a test owns an exclusive resource, xUnit 4 provides targeted opt-outs.
A theory whose rows must not overlap can declare: I do not want the verifier to trust that attribute merely because the two rows happened to run one after another.
The sample pull request includes a control configuration that compiles the same method without .
Two barriers force both control rows to attempt a one-at-a-time lease before either can release it.
Exactly one row fails.
The normal Release build restores the opt-out, and both rows pass.
The sample pins at and selects Microsoft Testing Platform in .
The official Microsoft Testing Platform setup guide covers that runner integration.
After restore, the validation uses no credentials or remote services.
When I would not enable full parallelization I would keep the default while a suite relies heavily on shared databases, fixed ports, process-wide environment variables, static mocks, or reused file paths.
Opting out every other test adds complexity witho