When would you put setup in Kotest's beforeSpec/afterSpec rather than beforeTest/afterTest, and what should you know about when those spec-level callbacks actually fire?

## The scope ladder Kotest gives you three useful scopes for fixture code, and choosing correctly is mostly a cost/isolation trade: - **Per test case** — `beforeTest`/`beforeEach`. Cheap, maximal isolation. Reset mocks, truncate tables, rebuild a small object graph. - **Per spec instance** — `beforeSpec`/`afterSpec`. Runs once around all the tests of that instance. Expensive, shared setup. - **Per project** — the project configuration surface, for a resource many specs share (one database, one broker). `beforeSpec` receives the `Spec` instance itself; `afterSpec` likewise. In practice you rarely use the argument except for logging or for reaching a property on a typed base spec. ```kotlin class ApiIntegrationTest : FunSpec({ lateinit var server: EmbeddedServer beforeSpec { server = EmbeddedServer().also { it.start() } } afterSpec { server.stop() } beforeTest { server.resetStubs() } test("returns 200 for a known id") { /* … */ } }) ``` That split is the canonical shape: the *expensive, reusable* thing is created once; the *dirty, per-test* thing is reset before every test. Getting it backwards — starting the server in `beforeTest` — is one of the most common causes of a slow Kotest suite. ## "Once per instance", not "once per class" This is the detail that separates a middle answer from a senior one. Kotest may construct the spec class more than once: that is exactly what the fresh-instance isolation modes do. `beforeSpec` fires once for **each instance the engine creates**, before that instance's first test. Under the default single-instance behaviour, one instance means one `beforeSpec` — which is why most people never notice. Turn on a per-leaf or per-test isolation mode and a `beforeSpec` that starts a container suddenly starts one per instance, and your suite time explodes (or your port is already bound and the whole spec errors). So the rule of thumb is: `beforeSpec` is *instance-scoped*. If you need something truly once per JVM run, own it at the project level or behind a lazily-initialised singleton whose second call is a no-op. ## Skipped specs skip their callbacks If every test in a spec is inactive — excluded by a tag expression, marked disabled, or filtered out by a test filter — Kotest has no work to do in that spec and its lifecycle callbacks do not fire. That is usually what you want (do not start a database for a spec nobody is running), but it means `beforeSpec` is not a "this class exists" hook. Registration, metric emission or global bookkeeping placed there will silently not happen on a filtered run, and people then chase a phantom bug in CI where a tag filter is active but locally everything works. ## Failure semantics A throwing `beforeSpec` is fatal for that spec: the tests are not run against a half-built fixture, and the failure is reported rather than swallowed. That is the correct behaviour — an unstarted server should not produce fifty confusing assertion failures. `afterSpec` failures are reported as well, which matters because teardown often runs against a resource that a failing test already broke. Write `afterSpec` so it cannot throw on top of the real failure: null-check, catch-and-log, or use a close helper that tolerates an already-closed resource. Kotest also has an auto-closing facility on the extension surface for exactly this reason. ## afterSpec versus a finally block Because `afterSpec` is a registered callback and not a `finally` inside your code, it runs even when tests fail — that is its point. But it does **not** protect you against a crashed JVM or a forcibly killed CI job; for containers and external resources, pair it with the tool's own reaper/lifecycle rather than assuming teardown always executes. ## Interaction with per-test hooks Ordering around a single test in a single-instance spec is: `beforeSpec` (once) → per-test callbacks around each test → `afterSpec` (once) after the last test. If you find yourself needing "before the first test only, but with per-test data", that is usually a design smell: keep the expensive object in `beforeSpec` and its mutable state reset in `beforeTest`. ## What interviewers listen for The cost argument for choosing spec scope; the precise statement "once per spec **instance**"; the awareness that filtered specs skip the callbacks; and defensive teardown. A candidate who says "beforeSpec runs once per class, always" has not operated a suite with a non-default isolation mode.