What does Kotest's assertionMode setting do when set to AssertionMode.Error in project config, and which test bugs does it catch?

## The problem it solves The worst test is not the failing one; it is the passing one that asserts nothing. It looks like coverage, it looks like verification, and it will never go red no matter how badly the code breaks. These appear naturally: ```kotlin test("rejects an expired token") { validator.validate(expiredToken) // and… nothing } ``` Someone deleted the assertion while debugging, or wrote the arrangement first and never came back, or the assertion sits inside a `forEach` over an empty list. All pass. All are worthless. ## The mechanism Kotest's assertion library keeps a count of assertions executed within a test. Every matcher call through that library (a `shouldBe`, a `shouldThrow`, a `should` with a matcher) bumps it. When the test completes, Kotest inspects the count and applies the configured `assertionMode`: ```kotlin package io.kotest.provided class ProjectConfig : AbstractProjectConfig() { override val assertionMode = AssertionMode.Error } ``` - **`None`** — the check is off. Any test may assert nothing. - **`Warn`** — assertion-free tests emit a warning but still pass. This is the migration setting. - **`Error`** — assertion-free tests fail. The setting is a project-level default, and like other defaults it can be relaxed for a spec that legitimately needs it. ## What it catches - Tests where the assertion was removed and not restored. - Placeholder tests that only exercise the system under test. - Tests whose assertions are inside a loop or lambda that never executes — the empty-collection case, which is the sneakiest of the family because the code *looks* like it asserts. - Tests where an early `return` or a swallowed exception skips the assertion. That third category is the one that justifies the setting on its own: a property or table-driven style test iterating an accidentally empty data set is invisible to review and to coverage tools, but not to an assertion counter. ## What it does not catch - **Weak assertions.** `result shouldNotBe null` counts. The check is about *presence*, not quality. - **Assertions from other libraries or hand-rolled checks.** The counter only knows Kotest's own assertion library, so a test doing `if (actual != expected) error("...")` counts as assertion-free and will be flagged even though it genuinely verifies something. - **Tests that assert the wrong thing.** It cannot read intent. ## Rolling it out On an existing suite, switching straight to `Error` produces a wall of failures mixing genuine no-op tests with tests using other assertion styles. The workable sequence: 1. Turn on `Warn` project-wide and collect the list. 2. Triage: delete or fix genuine no-op tests (usually a satisfying cull), and convert other-library assertions to Kotest matchers where cheap. 3. Exempt the specs that legitimately cannot use Kotest assertions, relaxing the mode for those specs only. 4. Flip the project default to `Error` so new no-op tests cannot land. Step 4 is the point of the exercise. `Warn` alone decays — warnings scroll past in CI logs and nobody reads them. The value comes from the setting being enforcing, which is exactly why it belongs in project config rather than being left to each spec. ## Why project config is the right home This is the archetype of a good global default: it encodes a suite-wide quality invariant, it should be uniform (a no-op test is no more acceptable in one module than another), and it fails loudly rather than changing behaviour subtly. Compare that with a global isolation mode, which changes semantics invisibly — the same mechanism, very different risk profile. ## Interview signal Strong answers describe the counting mechanism rather than treating it as magic, name the three modes, and volunteer both a limitation (only Kotest assertions are counted; weak assertions still pass) and a migration path (`Warn` → triage → `Error`).