In Kotest, test bodies and lifecycle callbacks are declared as suspending functions. What does the framework do differently because of that, and what does it change about how you write a test that touches suspending code?
answer
- test lambda is a suspend lambda
- beforeTest/afterSpec suspend too
- timeout enforced around the coroutine
- test scope implements CoroutineScope
- cancellation is cooperative — blocking code ignores it
basics
~20 sKotest invokes every test body — and every lifecycle callback like beforeTest and beforeSpec — inside a coroutine, so suspending calls are made directly with no wrapper builder. The test scope is itself a CoroutineScope, and Kotest enforces the test's configured timeout around that coroutine.
solid answer
~50 sKotest executes each test case as a coroutine, and the lambda you register is a `suspend` lambda. Consequences: - **Suspending calls need no wrapper.** `val user = service.loadUser(id)` compiles directly in a test body; there is no builder to wrap the body in. - **Lifecycle callbacks are suspending too** — `beforeTest`, `afterTest`, `beforeSpec`, `afterSpec` and friends — so setup that talks to suspending APIs does not need special treatment either. - **Kotest's own suspending assertions compose naturally**, which is why polling helpers such as `eventually` are suspend functions rather than thread-blocking sleeps. - **Timeouts are enforced around the coroutine.** A test's configured `timeout` (and `invocationTimeout` for repeated invocations) works because the body is suspending and therefore cancellable at suspension points. - **The test scope implements `CoroutineScope`**, so `launch`/`async` compile inside a body. That is a trap as much as a feature: prefer awaiting explicitly rather than relying on fire-and-forget work finishing before the test ends.
code
kotlin · 15 linesclass OrderServiceTest : FunSpec({
beforeSpec { broker.connectSuspending() }
afterTest { database.truncateAll() }
test("places an order").config(timeout = 5.seconds) {
val order = service.place(request) // suspend call, direct
order.status shouldBe Status.PLACED
}
test("awaits background work explicitly") {
val job = async { worker.process() } // test scope is a CoroutineScope
job.await() shouldBe Result.Ok
}
})go deeper
Know that you can call suspend functions directly in a Kotest test with no wrapper, and that setup callbacks work the same way.
Explain that Kotest runs each test as a coroutine, that lifecycle callbacks are suspending too, and that timeouts are enforced around that coroutine.
Add the nuances: cooperative cancellation means a blocking body defeats the timeout, the test scope is a CoroutineScope so background launches are possible and risky, and delays are real time unless you opt into Kotest's virtual-time configuration.
Frame it as an execution-model property that the rest of the framework builds on — suspending assertions, timeout enforcement, deterministic-time opt-in — and set a team rule against unawaited background work in tests.
## The design choice Kotest was built for Kotlin rather than adapted to it, and one of the visible consequences is that **the test lambda is a suspending lambda**. Every spec style registers bodies of the form `suspend TestScope.() -> Unit`. Kotest then runs each test case inside a coroutine it creates and controls. ```kotlin class UserServiceTest : FunSpec({ test("loads a user") { val user = service.loadUser(1) // suspend call, no wrapper user.name shouldBe "Ada" } }) ``` There is nothing to wrap the body in. The framework already established a coroutine context before invoking your lambda. ## Lifecycle callbacks get the same treatment This is the part candidates most often forget. Kotest's lifecycle DSL — `beforeSpec`, `beforeTest`, `afterTest`, `afterSpec`, container-level callbacks — is suspending as well. Setup that must talk to a suspending client, start a suspending server, or await a connection is written plainly: ```kotlin beforeSpec { server.startSuspending() } afterTest { database.truncateAll() } ``` So the suspending-by-default property is a property of the whole execution model, not just of the leaf test lambda. ## What the coroutine buys the framework Two things matter operationally. **Timeouts become real.** Kotest lets you configure a `timeout` per test (and `invocationTimeout` when a test is configured to run multiple invocations). Because the body is a coroutine, the framework can enforce that bound and cancel at suspension points, rather than being stuck with a thread it cannot safely stop. The important nuance: cancellation is cooperative. A body that blocks a thread in a tight non-suspending loop cannot be cancelled at all, and the timeout will not save you — the suspending model gives Kotest a *mechanism*, not a guarantee against code that never suspends. **Suspending assertion helpers compose.** Kotest's non-deterministic assertions are suspend functions that `delay` between attempts. That only works because the caller — your test body — is itself suspending. In a framework with blocking test methods those helpers would have to block a thread. ## The `CoroutineScope` on the test scope Kotest's test scope implements `CoroutineScope`, so this compiles: ```kotlin test("processes in background") { launch { worker.process() } // ... } ``` Treat that with care. Fire-and-forget work started in a test is a classic source of flakiness and of assertions that race against a job whose completion you never established. The disciplined pattern is to hold the handle and await it: ```kotlin test("processes in background") { val job = async { worker.process() } job.await() shouldBe Result.Ok } ``` If what you want is to observe an effect that genuinely arrives later, that is a job for Kotest's polling assertions, not for hoping a `launch` finished in time. ## Practical consequences for how you write tests 1. **Do not wrap the body in a coroutine builder out of habit.** Adding one nests an extra coroutine inside the one Kotest already made, which mainly costs you clarity — and if the wrapper blocks the thread, it also removes the cancellability the outer timeout depends on. 2. **Push setup that suspends into the suspending lifecycle callbacks** rather than into lazily-initialised blocking helpers. 3. **Be explicit about background work.** Await handles; do not rely on scheduling luck. 4. **Remember that a blocking call is still blocking.** Suspending test bodies do not make a JDBC driver or a `Thread.sleep` non-blocking; they only mean your *own* suspending code needs no ceremony. ## Where this sits relative to time control By default the coroutine Kotest creates uses real time and a real dispatcher: `delay` actually waits. Deterministic virtual time is a separate, opt-in Kotest configuration flag applied per test, per spec or project-wide — a distinct facility from the suspending-by-default execution described here. Knowing which of the two you are relying on is the difference between a test that waits and one that does not.
- Kotest enforces a per-test `timeout`. Why can a test still hang past it?Because coroutine cancellation is cooperative: the framework can only interrupt at suspension points. A body stuck in a non-suspending loop or a blocking native call never reaches one, so the timeout cannot take effect. The suspending execution model gives Kotest the mechanism to cancel, not immunity from code that refuses to yield.
- Is it a problem to start a `launch` inside a Kotest test body?It compiles because the test scope is a `CoroutineScope`, but it is usually a smell: you have created work whose completion the test never establishes, so assertions afterwards race it. Prefer `async` plus `await`, or an explicit join, and use Kotest's polling assertions when the effect genuinely becomes visible later through another component.
saying these in an interview costs you the question
- Wrapping every Kotest test body in a coroutine builder out of JUnit habit.
- Believing suspending test bodies make blocking calls non-blocking.
- Assuming lifecycle callbacks are ordinary blocking functions that need special handling for suspending setup.
- Thinking a configured timeout can always interrupt a stuck test, ignoring cooperative cancellation.
- Assuming suspending bodies imply virtual time — by default delays are real.