Which test settings can you set globally in Kotest's AbstractProjectConfig, and what wins when a spec or an individual test declares the same setting?

## The layer cake Kotest resolves each setting by asking the most specific source first and falling back outwards: ``` per-test .config(...) → spec (defaultTestConfig / spec properties) → project config → framework default ``` This is worth stating explicitly in an interview, because it explains almost every "my setting is ignored" report. A global default is exactly that — a default. It never overrides a local declaration. ## What lives at project level **Execution model** - `isolationMode` — the default spec instantiation strategy for every spec that does not declare its own. - `testCaseOrder` — the order in which tests within a spec are run. - concurrency settings (`parallelism`, and the concurrent-spec/concurrent-test knobs) — how much runs at once. **Time limits** - `timeout` — default limit for a single test. - `invocationTimeout` — limit for one invocation when a test is configured to run several times. - `projectTimeout` — an upper bound on the whole run, which is what stops a hung suite from occupying CI for an hour. **Strictness / hygiene** - `assertionMode` — whether a test that executed no Kotest assertion is a warning, an error, or ignored. - `duplicateTestNameMode` — what happens when two tests in a scope share a name. - `failOnEmptyTestSuite` — turns "nothing ran" from a green build into a failure, which catches broken filters and misconfigured includes. **Wiring** - `extensions()` — listeners and extensions applied to every spec. - `beforeProject()` / `afterProject()` — run-wide setup and teardown. You override only what you need; every untouched property keeps the framework default. ## How a spec overrides A spec can declare `defaultTestConfig` to change the defaults for all of its tests: ```kotlin class SlowIntegrationTests : FunSpec() { override fun defaultTestConfig() = TestCaseConfig(timeout = 2.minutes) init { test("imports a large file") { /* ... */ } } } ``` and an individual test overrides again: ```kotlin test("the really slow one").config(timeout = 10.minutes) { /* ... */ } ``` Some settings — isolation mode is the obvious one — are spec-shaped rather than test-shaped and have their own spec-level property. ## Choosing good globals A global default earns its place when uniformity is the point: - `failOnEmptyTestSuite = true` — nobody wants a green build from zero tests. - `duplicateTestNameMode` set to error — duplicate names silently hide tests in some styles and break reporting in others. - a generous `timeout` — a safety net so a hung test fails in a minute rather than blocking CI. - `assertionMode` — a whole-suite quality bar. - `extensions()` — cross-cutting infrastructure that must apply everywhere. A global default is a *bad* default when most specs override it. If half the suite raises the timeout, the global value is not expressing a shared decision; it is generating noise. Either raise it or accept per-spec declarations as the norm and drop the global. ## The discoverability cost The weakness of project config is invisibility. A developer reading a failing spec has no local hint that a global isolation mode, a global timeout, or a globally registered extension is in play. Two mitigations: keep the config small enough to read in one screen, and comment each override with *why*, not what. When a global setting is surprising in effect (isolation mode is the classic), prefer making it explicit per spec even at the cost of repetition. ## System properties and kotest.properties Several settings can also be provided outside the code — via JVM system properties or a `kotest.properties` file on the classpath. That is how a CI job tightens or loosens a run (for example forcing a stricter or looser configuration for one pipeline) without editing the config class. Treat it as an operational lever, not the primary home of your configuration: settings expressed in two places at once are a debugging tax. ## The interview signal Strong answers name a handful of real settings, state the precedence order confidently, and then say something about *policy*: which settings should be global because uniformity is the value, and which should be local because the exception carries information.