A Kotlin team enables parallel JUnit 5 execution on a suite that uses MockK's MockKExtension, and mocks start losing their stubs mid-test. What does the extension do that breaks under parallel execution, and how would you decide what to do about it?

## The mechanism that breaks MockKExtension ends a test (or a class, under the per-class instance lifecycle) by calling `unmockkAll()` followed by `clearAllMocks()`. Neither is scoped to the test that triggered it: - `unmockkAll()` reverses every global patch in the process — objects patched with `mockkObject`, file facades and Java statics patched with `mockkStatic`, constructors patched with `mockkConstructor`. - `clearAllMocks()` resets answers, recorded calls and child mocks on **every** registered mock in the JVM. Under serial execution that is the desired blast radius: whatever the finished test dirtied is cleaned. Under parallel execution the same call is a cross-test data race. Test A finishes and clears the world while test B, on another thread, is halfway between `every { }` and the call it stubbed. B then fails with "no answer found" for something it demonstrably stubbed, or silently loses its recorded calls so a `verify` reports zero invocations. The failures are non-deterministic, thread-timing dependent, and almost never reproduce when you rerun the single test — which is exactly why people misdiagnose them as MockK bugs. ## What MockK offers `@MockKExtension.RequireParallelTesting` (class level) or the JUnit Platform configuration parameter `mockk.junit.extension.requireParallelTesting=true` tells the extension to skip those global calls. `@MockKExtension.KeepMocks` — allowed on a class *or* a single method, or `mockk.junit.extension.keepmocks=true` — suppresses the same two calls, though its intent is "I want the mock state to survive" rather than "I run in parallel". One precise detail worth carrying: suppressing cleanup does **not** suppress the strictness checks. If a class also carries `@MockKExtension.ConfirmVerification` or `@MockKExtension.CheckUnnecessaryStub`, those still run — and they too look at *all* registered mocks, so under parallelism they can observe another test's interactions. Strict checking and parallel execution are a bad pairing. ## What you own once cleanup is off **Instance mocks are mostly fine on their own.** With JUnit's default per-method test instance, each test gets its own annotated mocks, so there is no sharing to protect. Turning cleanup off costs you only the reset of mocks nobody else can see — plus memory held until the JVM ends. **Global patching is not fine, ever.** `mockkObject`, `mockkStatic` and `mockkConstructor` mutate state shared by the whole process. Two concurrent tests patching the same object, or one patching while another calls the real thing, cannot be made safe by any extension option — the sharing is in the production construct, not in MockK's bookkeeping. And with cleanup suppressed, a patch installed by one test now leaks to every later test in the fork. **You need a replacement teardown.** If a class both patches globals and opts out of cleanup, it must unpatch itself explicitly, and it must not run concurrently with anything that touches the same construct. ## The judgment call I would frame it as: *what am I buying, and what class of failure am I importing?* 1. **Measure first.** If mock-heavy unit tests are seconds of the build and integration tests are minutes, parallelising them buys nothing. Fork-level parallelism at the build-tool layer often gives most of the win with none of this problem, because each fork is a separate JVM with its own global state. 2. **Segment the suite.** Classes that use only plain instance mocks are candidates for concurrency. Classes that patch objects, statics or constructors get pinned to serial execution using the test framework's execution-mode controls, and stay there permanently. 3. **Make the constraint enforceable.** "Don't use mockkStatic in a parallel class" as a code-review convention decays. A single project annotation that combines extension registration, serial execution and normal cleanup — applied to every global-patching class — encodes it once. 4. **Do not mix strictness with parallelism.** Global `confirmVerified()`/`checkUnnecessaryStub()` observe all mocks; concurrent tests make them flaky. Pick one. 5. **Prefer removing the need.** Most `mockkStatic`/`mockkObject` usage exists because production code reaches for a global. Injecting that dependency instead deletes the whole category of problem, gives faster tests, and is usually the better place to spend the effort. ## The short version to say out loud The extension's cleanup is JVM-wide, so parallel tests clear each other. `@MockKExtension.RequireParallelTesting` suppresses it, but that only removes MockK's own interference — anything patched globally remains genuinely shared. So: parallelise the classes that only use instance mocks, keep global-patching classes serial, keep strictness checks out of the parallel set, and be sure the wall-clock saving is worth the flakiness budget.