How would you set the mock-isolation policy for a large Kotlin test suite that uses MockK — fresh mocks per test, clearMocks/clearAllMocks, or unmockkAll teardown — and what are the tradeoffs of each?

## What the policy has to achieve One property: **no test's outcome depends on what ran before it.** Everything else — how much you clear, where teardown lives — is a means to that end. Policies fail when they optimise for ritual ("always call clearAllMocks") instead of for the property. ## Tier 1: recreate rather than reset The strongest isolation is a double that does not survive the test at all. If mocks are created in per-test setup, there is no stub table to go stale and no call log to accumulate. Mock creation is cheap relative to almost anything else a test does. This should be the default, and a suite that follows it needs no `clearMocks` at all for ordinary collaborators. A `clearMocks` call at the top of a test whose mocks are already created per test is dead code — it signals that someone did not know where the state lived, and it should be deleted in review. **Tradeoff**: none worth mentioning for ordinary mocks; it only becomes a question when a double is expensive to build or is wired into a fixture that itself is expensive. ## Tier 2: clearMocks, deliberately and narrowly Two legitimate cases: - **Shared fixture.** A double built once for a class because construction is genuinely costly, or because it is injected into a long-lived component that cannot be rebuilt per test. Then a per-test `clearMocks` restores the illusion of freshness. - **Mid-test reset.** A test with distinct phases that wants counts from zero without re-declaring stubs: `clearMocks(repo, answers = false)`. **Tradeoffs.** Clearing is a plain function call and therefore ordering-sensitive — if it runs after the code that configures stubs, it removes them and the failure ("no answer found") points at a line where the stub is plainly visible. It is also incomplete by nature: it resets state but never removes instrumentation, so it can never be the answer for a leaked global patch. And a blanket clear hides which state actually mattered, which makes the next isolation bug harder to reason about. Rule: one place per suite where clearing happens, with a comment saying which shared fixture it serves. ## Tier 3: global patches need structural teardown `mockkObject`, `mockkStatic` and `mockkConstructor` are installations in a process-wide registry, not values. No test boundary removes them, and `clearAllMocks` explicitly does not. This is the tier where a policy earns its keep. Preference order: 1. **Don't patch.** Inject the collaborator instead. Most `mockkObject` calls exist because a singleton is reached directly from production code; fixing that removes the test problem and improves the design. 2. **Scoped blocks.** MockK 1.13's `mockkObject(X) { ... }` / `mockkStatic("...") { ... }` / `mockkConstructor(X::class) { ... }` remove the registration on exit, including on failure. Nothing to remember, nothing to forget. 3. **Symmetric teardown in one shared place.** Targeted `unmockkObject`/`unmockkStatic` where the test knows exactly what it installed; `unmockkAll()` where a sweep is acceptable. Note that a blanket sweep also tears down patches installed by an enclosing fixture, which is a real hazard in suites with shared base classes. **Tradeoff of blanket unmockkAll**: it is safe and forgiving, but it makes setup and teardown asymmetric, so nobody can tell from a test what it actually patched. ## Making the policy stick - Put teardown in one shared base fixture rather than in individual tests; a rule that depends on everyone remembering will be broken within a month. - Review new occurrences of the global patching functions — the count should be flat or falling. - Randomising or varying execution order surfaces order dependence early instead of on the day someone adds a test in the middle. - When an isolation bug appears, fix the *category*, not the instance: if one forgotten `unmockkStatic` slipped through, the answer is scoped blocks, not one more teardown line. ## The summary I would give "Fresh mocks by default, clearing only for shared or phased fixtures and only in one place, and global patches either scoped to a block or torn down in a single enforced teardown. Clearing resets state; only unmocking removes instrumentation — a policy that confuses the two will keep producing order-dependent failures."