Kotest's core artifacts and its integration modules for Spring, Testcontainers, WireMock and Koin are published as two different families. Why does that split matter in practice when you maintain a real test suite?

## Two families, two release trains Kotest publishes core functionality under the `io.kotest` group — the runner, the assertion library, property testing, data-driven testing — and its integrations under `io.kotest.extensions`, from a separate repository with its own releases. The extension family is where the Spring extension, the Testcontainers extension, the WireMock extension, the Koin extension, the Ktor assertions and the Arrow assertions live. That is an ordinary and sensible arrangement: an integration's release cadence is driven partly by the library it integrates with, which has nothing to do with when the core framework ships. But it has practical consequences a maintainer feels. ## Consequence 1: version numbers do not transfer The single most common setup mistake is assuming one version number spans everything. It does not. The core artifacts move together and can be aligned centrally — Kotest publishes a BOM (`kotest-bom`) for exactly that — but an extension's version is its own. Reusing the core version for an extension usually produces a "not found" resolution error, and occasionally something worse: a stale extension that resolves but was built against an older core. Practically: pin extension versions explicitly and separately, and treat a core upgrade as a moment to check whether the extensions you use have a matching release. Sometimes they will lag a major core version by weeks or longer, which is a real input into when you upgrade. ## Consequence 2: each extension is a coupling Adding an integration module couples the suite to three things at once: 1. the third-party library itself (Spring, Testcontainers, WireMock, Koin); 2. the extension's own release cadence; 3. the core Kotest version the extension supports. When those three fall out of alignment, upgrading any one of them can stall. So the adoption test is worth stating plainly: **an extension earns its place when it manages a lifecycle you would otherwise hand-roll**. Starting and stopping a container, guaranteeing teardown on the failure path, resetting a mock server between tests, or wiring a spec into a framework's test-context machinery are all things that are tedious and easy to get wrong by hand — and where the failure mode (leaked containers, state bleeding between specs) is expensive. By contrast, a fixture that is a couple of lines of setup does not need an integration module. The version surface you take on is not free. ## Consequence 3: the core is more decoupled than people assume The flip side is genuinely useful. `kotest-assertions-core` does not depend on the Kotest runner — its matchers raise ordinary assertion errors, so they work in tests executed by any JVM test framework. `kotest-property` is likewise usable outside Kotest specs. That makes incremental adoption cheap: bring in the matcher module purely for readability, leave the runner and spec styles for a later, separate decision, and abandon it just as cheaply if the team dislikes it. The same decoupling means an existing Kotest suite can keep using another assertion library where it already has investment; nothing forces uniformity at the assertion layer. ## Consequence 4: only add the modules you use JSON assertions, property testing and data-driven testing are separate artifacts on purpose. A suite that does not do property testing should not carry the property module. This keeps the test classpath small, which matters for resolution time and for the size of the dependency surface a security scan has to reason about. ## Consequence 5: know which family owns a problem When something breaks, the family tells you where to look. A spec that does not run at all points at the runner artifact. An unresolved `withData` or `Arb` points at a missing core module. A container that will not start, or an extension that no longer compiles after a Kotest upgrade, points at the extensions family and its independent versioning. That triage instinct is most of the practical value of knowing the split exists. ## What a strong answer includes Name the two groups, state that the extension family releases independently so version numbers do not transfer, mention the BOM for aligning core artifacts, and give the adoption test for extensions (lifecycle management versus a couple of lines of setup). Adding the runner-independence of the assertion modules — and what it enables for incremental adoption — is what turns a factual answer into a maintenance-judgement one.