What does Kotest's autoClose function do inside a spec, when does the resource get closed, and where does it let people down?

## What it is `autoClose` is a small convenience on `Spec`: ```kotlin fun <T : AutoCloseable> autoClose(closeable: T): T fun <T : AutoCloseable> autoClose(closeable: Lazy<T>): T ``` You wrap a resource at the point you create it, and Kotest remembers to close it when the spec is done. It returns the same object, so the idiom reads naturally: ```kotlin class DbTests : FunSpec() { private val db = autoClose(EmbeddedDb()) private val client = autoClose(HttpClient()) init { test("round trips") { /* uses db and client */ } } } ``` It replaces the boilerplate of an `afterSpec` that closes three things in the right order and remembers to null-check each one. ## When it fires At spec teardown — after the spec instance's tests have finished — and in **reverse order of registration**. Reverse order matters: if `client` was registered after `db` and depends on it, `client` closes first, mirroring how nested `use` blocks unwind. It fires whether the tests passed or failed. What it cannot promise is anything the JVM cannot promise: kill the process and no close runs. Resources whose leak survives the process (external containers, cloud fixtures) need external reaping regardless. Do not build logic that depends on a precise interleaving with your own `afterSpec` code. If a teardown step must observe the resource open, either do that work before the spec ends or drop `autoClose` and close explicitly in `afterSpec` where you control the order. ## The lazy overload ```kotlin private val db by lazy { EmbeddedDb() } // wrong: never registered private val db = autoClose(lazy { EmbeddedDb() }) // registered, closed only if used ``` The `Lazy` overload exists precisely so that an expensive resource is created only if some test touches it, while still being closed if it was. Wrapping the eager value defeats laziness (you construct it immediately); wrapping a plain `by lazy` delegate registers nothing at all. ## The isolation trap This is the point interviewers push on. `autoClose` is a method on a spec **instance** and registers into that instance. Under a non-single isolation mode Kotest creates a new instance per test (or per leaf), and each instance: 1. runs the property initialiser, constructing a new `EmbeddedDb()`, 2. registers it, 3. closes it at that instance's teardown. So a twenty-test spec opens and closes twenty databases. If the resource is cheap, this is a feature — perfect isolation. If it is a container or a server, it is a disaster, and nothing warns you: the diff that changed the isolation mode is nowhere near the spec that got slow. For a resource that should exist once per spec class, use `PrepareSpecListener`/`FinalizeSpecListener`; for once per run, a `ProjectListener` registered in project config. `autoClose` is the right tool only for per-instance resources. ## Other sharp edges - **It only knows `AutoCloseable`.** A resource with `stop()`, `shutdown()`, or `dispose()` needs a tiny adapter, or an explicit `afterSpec`. - **It closes; it does not reset.** Between tests within one instance, nothing happens. Per-test cleanup is a different hook. - **Registration happens when the call executes.** A resource created inside a test body and wrapped there is registered at that moment — usually you want it wrapped at spec construction so the intent is visible at the top of the file. - **Failures during close.** If `close()` throws, that surfaces during teardown rather than as a test failure; make close idempotent and tolerant so one broken resource does not obscure the real test result. ## Rule of thumb Use `autoClose` for cheap, instance-scoped `AutoCloseable`s where you want the close to be impossible to forget. The moment the resource is expensive or shared, move its lifecycle up to a class- or project-level listener and stop thinking of it as spec state.