In a Kotest 5 spec, what does defaultTestConfig do, and how does it differ from calling .config(...) on an individual test?

## One settings bundle, three scopes Kotest expresses per-test settings as a `TestCaseConfig`. The same bundle appears at three scopes: - project — global defaults in `AbstractProjectConfig` (individual properties such as `timeout`), - spec — `defaultTestConfig` for every test in the spec, - test — `.config(...)` on a single test. Resolution is most-specific-wins, so the mental model is a three-layer default chain, not three independent switches. ## What is in a TestCaseConfig - `enabled` / `enabledIf` — whether the test runs at all (a static flag, or a predicate evaluated for the test case). - `invocations` — run the test body more than once. - `timeout` — limit for the whole test. - `invocationTimeout` — limit for a single invocation when `invocations` > 1. - `tags` — Kotest tags used for filtering. - `extensions` — `TestCaseExtension`s attached at this scope. - `severity` — the severity level attached to the test. Anything you leave unset falls through to the next layer out. ## Spec scope: defaultTestConfig ```kotlin class IntegrationTests : FunSpec() { override fun defaultTestConfig() = TestCaseConfig( timeout = 2.minutes, tags = setOf(Integration) ) init { test("reads from the database") { /* ... */ } context("when the queue is empty") { test("returns nothing") { /* also 2 minutes, also tagged */ } } } } ``` Two things matter here. First, it reaches **nested** tests, not just top-level ones — the baseline is for the spec, not for a scope. Second, it is a genuine baseline: a test that sets only `timeout` in its own `.config(...)` still inherits the spec's tags. This is the natural home for facts about the whole spec. "Every test in this file talks to a real database" should be stated once as a tag and a timeout, not repeated on twenty tests where the twenty-first will be forgotten. ## Test scope: .config(...) ```kotlin test("the enormous import").config(timeout = 10.minutes, invocations = 1) { /* ... */ } ``` The narrowest scope, and the most visible: the setting sits on the line a reader is already looking at. That visibility is why exceptions belong here and rules belong at spec or project level — a reader who sees a ten-minute timeout on one test knows immediately that this test is special. ## Choosing between them | Situation | Where | |---|---| | Every test in this spec is slow / tagged / needs an extension | `defaultTestConfig` | | One test is the exception | `.config(...)` | | Every spec in the project should behave this way | project config | A useful smell test: if you find yourself copying the same `.config(...)` onto each test in a spec, hoist it. If you find yourself overriding the same project default in most specs, the project default is wrong. ## Common mistakes - **Expecting it to override a per-test setting.** It cannot; the test wins. - **Expecting it to apply outside the spec.** It is spec-scoped; a sibling spec is unaffected. - **Confusing it with isolation mode.** Isolation is a property of how the *spec* is instantiated, not of a test case, and has its own spec-level property. - **Assuming an unset field means 'framework default'.** Unset means "inherit from the next layer out", which may be a project value you forgot about. - **Using tags here and expecting them to change what runs without a filter.** Tags only affect selection when a tag expression is active. ## Interview signal A good answer states the layering rather than describing two unrelated APIs, names a couple of real `TestCaseConfig` fields, and offers the hoisting heuristic — rules go outward, exceptions stay local and visible.