How do you set Kotest's isolation mode for one spec versus for a whole project, and which setting wins when both are present?

## The two places the mode can be declared Kotest resolves a spec's isolation mode from the narrowest declaration outwards. ### Spec level The spec class exposes an overridable function returning the mode: ```kotlin class CartTest : FunSpec({ test("…") { } }) { override fun isolationMode() = IsolationMode.InstancePerLeaf } ``` Because the spec body is a constructor lambda, the override lives in a class body attached after it — which is why specs that configure anything are written with the `{ … }) { … }` shape. The same pattern is used for other per-spec settings. A shared base spec can carry the override so a whole family of specs gets the same isolation without repeating it: ```kotlin abstract class IsolatedSpec(body: FunSpec.() -> Unit) : FunSpec(body) { override fun isolationMode() = IsolationMode.InstancePerLeaf } ``` ### Project level The project configuration class — a subclass of `AbstractProjectConfig` — carries a project-wide default: ```kotlin class ProjectConfig : AbstractProjectConfig() { override val isolationMode = IsolationMode.InstancePerRoot } ``` That value applies to every spec that does not state its own. (How Kotest discovers the project config class is a separate configuration topic; here what matters is the precedence relationship.) ## Precedence Spec beats project; project beats the framework default. If no one declares anything, Kotest uses `SingleInstance`. The rule is a simple override, not a combination: a spec asking for `SingleInstance` gets exactly that even when the project default is a fresh-instance mode — there is no "most isolating wins" merge. That cuts both ways, and it is worth saying out loud in an interview: a spec can *opt out* of a stricter project default just as easily as it can opt in to a stricter one, so a project-wide isolation policy is a default, not an enforcement mechanism. ## How to use the two levels well **Keep the project default cheap.** Changing it is a suite-wide change: every spec body and every container block starts re-executing more often, heavy `beforeSpec` setup is multiplied, and side effects written inside container blocks are duplicated. On a large suite that can turn minutes into tens of minutes and can turn green into red for tests that assumed a container's setup ran once. If you do want a stricter project default, roll it out and measure, rather than flipping it in a Friday commit. **Opt in where it pays.** Legacy specs full of accumulated mutable state are the honest use case for a per-spec fresh-instance mode: you get correct isolation now, and you can refactor the state out later. New specs should generally not need it — build mutable fixtures inside the test or rebuild them in `beforeTest`, and the default mode is both faster and clearer. **Prefer the coarsest mode that solves the problem.** If tests only pollute across top-level branches, `InstancePerRoot` (Kotest 6.0+, the recommended fresh-instance mode in Kotest 6) costs far less than a per-leaf mode. **Make the choice visible.** A spec whose behaviour depends on its isolation mode should say so near the top; a reader who does not see the override will reason about shared state incorrectly. Some teams enforce it via a base spec so the mode is declared in exactly one place. ## Common mistakes - Declaring the mode inside the spec *body* lambda by assigning a local variable and expecting it to take effect — the override belongs to the class, and a stray local does nothing. - Assuming a stricter project default protects every spec; a spec-level declaration silently overrides it. - Setting a fresh-instance project default to fix one leaky spec, paying the cost across the whole suite. - Expecting the mode to affect anything outside the spec object — it does not reset companions, singletons or external systems. ## What interviewers listen for The two mechanisms named precisely, the direction of precedence, and the judgement that project-wide isolation changes are a performance and behaviour event rather than a config tweak.