If you switch a nested Kotest spec from the default single-instance behaviour to IsolationMode.InstancePerLeaf, what re-executes for each test — the spec body, container blocks, beforeSpec, beforeTest — and what does that cost you?

## What a "fresh instance" actually implies Kotest's spec body is not a static description that the engine parses once; it is executable Kotlin that registers tests as it runs. So constructing a new spec instance necessarily means **running that body again**. Under `InstancePerLeaf`, that happens once per leaf test. For a leaf buried two containers deep, the sequence per leaf is: 1. **Construct the spec** → the spec body executes, registering the whole tree again and re-creating every property declared in it. 2. **beforeSpec fires** for this instance — spec-level callbacks are per *instance*, not per class. 3. **Walk the path**: the outer container body executes, then the inner container body executes; each is a test case, so `beforeContainer`/`beforeTest`/`beforeAny` fire for them. 4. **Run the target leaf** with `beforeEach`/`beforeTest` before it and the `after…` counterparts after it. 5. **afterSpec fires** for that instance once its work is done. Siblings of the target leaf are registered but not executed in that instance — that is precisely how the isolation is achieved. ## Counting the re-executions ```kotlin class S : FunSpec({ println("body") context("outer") { println("outer") test("one") { } test("two") { } test("three") { } } }) ``` Under the default single-instance behaviour: `body` once, `outer` once, three tests. Under `InstancePerLeaf`: `body` three times, `outer` three times, three tests. The multiplier is the number of leaves under each container — which in real suites with five to twenty tests per context is a five- to twenty-fold increase in the cost of that container's setup. ## Where it hurts **Duplicated side effects.** This is the big one, and it is a *correctness* problem, not just a speed problem. Container bodies in the wild often do work: seeding a table, publishing an event, configuring a global stub, incrementing a counter that a later assertion checks. Re-executing the container per leaf repeats that work. Tests that asserted "one row exists" now see N. Verification of "the collaborator was called once" now sees N if the collaborator is a shared singleton mock. The fix is to make container bodies *declarative* — build values, do not perform effects — and put effects in lifecycle hooks whose firing count you control. **Multiplied spec-level setup.** A `beforeSpec` that starts an embedded server or a test container now runs per instance. Best case the suite crawls; worst case the second start fails because the port is bound or the container name is taken, and the spec errors out. Heavy resources belong at the project level (one per run) or behind a lazily-initialised singleton whose second call is a no-op — precisely because their lifecycle should not follow the spec's instance count. **Non-obvious interaction with expensive registration.** If the spec body itself does work — reading a fixture file, computing a large data set for `withData` — that too repeats per leaf. ## What does *not* change - Per-test callbacks still fire per test case, exactly as before; the mode does not add or remove them. - Global state is untouched: companion objects, singletons, static caches, database rows and files survive re-instantiation, so a leak living there is unaffected by the switch. - Assertions, matchers and test names are unchanged. ## Choosing a cheaper point on the curve `InstancePerTest` is strictly more re-execution than `InstancePerLeaf`, since containers get instances of their own as well. In the other direction, `InstancePerRoot` (added in Kotest 6.0 as the recommended mode, where the other two fresh-instance modes are deprecated) gives one instance per top-level test case: each root's containers execute once, and everything under that root shares the instance. If the pollution you are fighting is between top-level branches, that buys the isolation you need at a bounded cost. The cheapest option of all is usually not a mode change: keep the default, make spec-level and container-level declarations immutable, and rebuild the mutable parts in `beforeTest`/`beforeEach`. Fresh-instance modes are the blunt instrument for suites you cannot easily refactor. ## Diagnosing after a switch When someone flips the mode and the suite goes red or slow, the diagnostic is mechanical: add a `println` (or a counter) in the spec body and in each container body, run one spec, and count. The counts tell you immediately which block is being multiplied, and the fix is to move the effect out of that block into a hook or out of the spec entirely. ## What interviewers listen for The explicit statement that the spec body and the container path re-execute; `beforeSpec` being per instance; the correctness angle (duplicated effects) rather than only the speed angle; and knowing a cheaper mode exists.