A Kotest spec passes when you run a single test on its own but fails when the whole class runs, and the spec body holds a mutable list the tests add to. Explain the mechanism and the ways to fix it.

## The mechanism A Kotest spec body is a lambda that runs once *per spec instance* to register tests. Anything you declare in it — `val queue = mutableListOf<String>()`, `var counter = 0`, a mock, a builder — is a property of that instance, created when the body runs. The default isolation mode is `SingleInstance`: Kotest constructs the class once and executes every test in it against that one object. So a mutable property is shared by all tests in declaration order. Test 1 appends two items; test 2 asserts `list shouldHaveSize 1` and sees three. In isolation test 2 passes; in the suite it does not. The same reasoning applies one level down in nested specs: a `context("…") { }` body also runs once under SingleInstance, so anything built inside a container is shared by all leaves beneath it — a subtler version of the same bug, because the state *looks* scoped to the group. ```kotlin class CartTest : FunSpec({ val cart = mutableListOf<String>() // one list for the whole class test("adding one item") { cart += "apple" cart shouldHaveSize 1 // passes } test("adding another item") { cart += "pear" cart shouldHaveSize 1 // fails: size is 2 } }) ``` ## Why it shows up as flakiness The failure is order-dependent, so anything that changes order or membership changes the outcome: running a single test from the IDE, a tag filter that removes the polluting test, a different spec ordering setting, or someone inserting a new test in the middle. Teams often mislabel this as flakiness and retry it away, which hides a genuine defect in the test design and sometimes in the code under test (a shared cache that should not be shared). ## The fixes, ranked ### 1. Don't share state at all Move the declaration into the test body. Each test then constructs exactly what it needs and nothing survives. For a small object graph this is the cheapest, clearest fix and it makes the test readable in isolation — a property good tests have anyway. ### 2. Rebuild or reset per test in a hook When construction is non-trivial, keep the declaration at spec level but rebuild it: ```kotlin lateinit var cart: MutableList<String> beforeTest { cart = mutableListOf() } ``` Reassigning is safer than mutating (`cart.clear()`), because reassignment cannot miss a field that a nested structure accumulated. Use `beforeEach` rather than `beforeTest` in a nested spec if you want the reset only for leaf tests. ### 3. Change the isolation mode ```kotlin override fun isolationMode() = IsolationMode.InstancePerLeaf ``` Now Kotest constructs a fresh spec instance per leaf test, re-running the spec body (and the container path down to that leaf), so every test sees a newly built list. It is the most sweeping fix and the most expensive: the body and containers re-execute per leaf, side effects inside container bodies are repeated, and the suite gets slower. Use it when a spec genuinely needs per-test freshness for many pieces of state, not as a reflex for one leaky list. On Kotest 6 `InstancePerRoot` is a cheaper middle ground when the pollution is between top-level branches rather than between siblings. ## The limit worth stating unprompted Isolation mode isolates the **spec object**. It does nothing about: - `companion object` / top-level / `object` state — per class or per process, not per instance; - singletons and static caches inside the code under test; - external systems: database rows, files, message queues, an in-memory server that keeps running; - global mock or stub registries. If a test still leaks after switching modes, the state lives in one of those places, and the answer is an explicit reset in a lifecycle hook, a fresh external resource per spec, or removing the global state from the design. ## Diagnosing it quickly Run the failing test alone — if it passes, you have order dependence. Then bisect: run the suspect pair together. Reading the spec for `var`/mutable collections declared outside test bodies usually finds the culprit in seconds. A useful discipline in review: spec-level declarations should be immutable and stateless (a service under test with no mutable fields, a pure fixture), and everything mutable should be created per test. ## What interviewers listen for Naming SingleInstance and explaining *why* one instance implies shared state; giving more than one fix and ranking them by cost; and the maturity signal — knowing that switching isolation mode does not clean up companions, singletons or the database.