Isolation Modes

## What isolation mode actually controls A Kotest spec is a class whose body registers tests. `IsolationMode` answers one question: **how many times does Kotest construct that class during the run?** Everything else — what state is shared, which blocks re-execute, how expensive the suite is — falls out of the answer. ## The modes ### SingleInstance One instance for the whole spec. The body runs once, registering the tree; then all tests execute against that single object. Any `var`, `lateinit var` or mutable collection declared in the spec body is therefore **shared by every test**, and mutations made by one test are visible to the next. This is the default and the fastest mode; it is also the mode in which order-dependent tests hide. In a nested spec, a container body also runs once, so state built inside a `context { }` is shared by all leaves under it. ### InstancePerRoot A fresh instance per **root-level** test case — each top-level `test`/`context`/`describe`/`given`. Everything nested beneath one root executes inside that one instance, sequentially, so siblings deep in a tree still share state with each other, but two different top-level branches never do. The instance count is bounded by the number of roots, which keeps the cost predictable while removing the worst cross-branch leakage. ### InstancePerTest A fresh instance for **every** test case — containers as well as leaves. To run a given node, Kotest creates the instance, re-executes the spec body (which re-registers the tree), walks down the containers on the path to the target node executing them, and then runs the target. Because containers are themselves targets, a container's body ends up executing for the container's own "turn" as well as for each descendant's turn. Maximum isolation, maximum re-execution. ### InstancePerLeaf A fresh instance for each **leaf** test. The container path leading to that leaf is re-executed in the new instance so the leaf sees the same context, but containers do not get instances of their own. This is the mode people usually mean when they say "I want each test to start clean" in a nested spec: sibling leaves cannot see each other's mutations of spec-level or container-level state. ## A concrete count ```kotlin class S : FunSpec({ context("a") { test("a1") { } test("a2") { } } test("b") { } }) ``` Test cases: container `a`, leaves `a1`, `a2`, `b`. - **SingleInstance** — 1 instance; `a`'s body runs once. - **InstancePerRoot** — 2 instances (roots are `a` and `b`); `a1` and `a2` share one instance, so they still share whatever `a`'s body built. - **InstancePerLeaf** — 3 instances, one per leaf; `a`'s body re-executes on the way to `a1` and again on the way to `a2`. - **InstancePerTest** — an instance for each of the four test cases, with the container path re-executed each time. ## Why the trade exists More instances means more isolation and less spooky action at a distance, but every extra instance re-runs the spec body and the container path. If a container starts a service, seeds ten thousand rows or sleeps, that cost is multiplied. Worse, side effects in container bodies are *repeated*, not just recomputed: an insert placed in a container will happen once per leaf under a per-leaf mode, and "exactly one row" assertions start failing. Fresh instances also do nothing for state that does not live in the instance — `companion object` fields, singletons, static caches, real database rows and files all survive re-instantiation. ## Versions Assume Kotest 5.x. `SingleInstance`, `InstancePerTest` and `InstancePerLeaf` are long-standing; `InstancePerRoot` was added in Kotest 6.0 as a simpler, cheaper middle ground, and in Kotest 6 it is the recommended mode while `InstancePerTest` and `InstancePerLeaf` are deprecated. If you are writing new code on a recent version, reach for `InstancePerRoot` before the finer-grained modes. ## What interviewers listen for Counting instances correctly for a nested example; knowing that the container path re-executes rather than being replayed from a cache; naming the default; and — the mature point — knowing that isolation mode isolates the *spec object*, not the world.