Kotest: assertions, property testing and specs for Kotlin, including multiplatform targets

The gap Kotest fills in a Kotlin test suite

JUnit gives Kotlin code a runner and an assertion API shaped around Java. Kotest is a testing tool for Kotlin with multiplatform support, and it is split into modules rather than shipped as one jar, so a team can take the assertion library without adopting the test engine. The repository layout shows the split plainly at the top level: kotest-assertions, kotest-property, kotest-framework, kotest-runner, kotest-common and kotest-extensions are separate Gradle projects, with kotest-bom available for version alignment.

The audience is Kotlin developers who write tests in Kotlin and want the test code to read like Kotlin. The README describes the project as flexible and comprehensive, and the topics list includes assertions, matchers, property testing, kotlin-multiplatform, kotlin-js and testing-tools. That combination is the pitch: one ecosystem covering the assertion layer, the spec style and the runner, rather than three libraries from three maintainers.

Who it is not for matters as much. A Java service with no Kotlin source gains nothing here, because the assertions and the spec DSL are Kotlin constructs. A team that has standardized on JUnit 5 and is happy with it also has little to gain, since Kotest's runner is a JUnit platform engine and can coexist with existing tests.

How the modules and runners fit together

The architecture is a layered set of Gradle modules. kotest-assertions holds the matchers, kotest-property holds generators and shrinking for property based tests, kotest-framework holds the engine that discovers and executes specs, and kotest-runner holds the adapters that make the engine visible to a build tool. kotest-common carries shared code, and kotest-extensions holds optional integrations.

The runner side is where the build integration lives. The README's version badge points at io.kotest:kotest-runner-junit5 on Maven Central, which tells you the primary path into a JVM build is through the JUnit platform. That is a design decision with a consequence: Kotest does not need to replace your existing test infrastructure, it plugs into the same discovery mechanism JUnit 5 uses. A project can run Kotest specs and JUnit tests in one Gradle test task.

Because the modules are published separately, the dependency you add determines what you get. Adding only the assertion artifact gives matchers and no spec DSL. Adding the runner artifact pulls in the engine. The kotest-bom module exists so that a multi-module build can pin one version across all of them instead of repeating coordinates.

Installing Kotest with Gradle and running a first spec

The README points readers at the quick start guide on kotest.io for getting started, and the version badge references io.kotest:kotest-runner-junit5 on Maven Central. The repository is a Gradle build with a gradlew wrapper at the root, and the published artifacts are resolved through normal Maven or Gradle coordinates. The README does not print a dependency snippet or a spec body, so there is no install block to copy here; the coordinates named in the badge are io.kotest:kotest-runner-junit5, and the release you intend to use should be confirmed on Maven Central before you add it to a build.

What the README does give is the shape of the workflow. You add the runner artifact to your test dependencies, you write specs that extend a spec style from the framework module, and you run your build's existing test task. Because the runner is a JUnit platform engine, Kotest specs appear in the same discovery pass as any JUnit tests already in the source set. If nothing is discovered after adding the dependency, the first thing to check is whether the runner artifact actually landed on the test classpath, since discovery depends on it rather than on the spec class itself.

The quick start guide on kotest.io is where the project sends readers for the concrete dependency lines and the first spec example. That is the right place to copy from, because the module list changes between releases and a snippet taken from a blog post or an old answer can reference an artifact that no longer matches the current line.

Where Kotest costs you time

The module split is the main source of friction for newcomers. A reader who adds one artifact and expects the whole framework gets a subset, and the error surfaces as an unresolved import rather than a clear message. Working out which of kotest-assertions, kotest-property, kotest-framework and kotest-runner you actually need is the first task, and the README does not walk through that mapping; it defers to kotest.io.

The version cadence is the second cost. The releases listed for this repository run v6.2.3 in July 2026, v6.2.4 in August 2026 and v6.2.5 in September 2026, with the last push to the default branch on 2026-09-20. Frequent patch releases are good for fixes and less good for anyone who pins versions loosely across many modules, which is exactly the situation kotest-bom addresses.

Finally, Kotest is a Kotlin testing framework, and that is a hard boundary. If your test sources are Java, the assertion DSL and the spec styles do not apply, and the sensible choice is to stay on JUnit. There is no documented path in the README for writing Kotest specs in Java.

Kotest compared with JUnit 5 and with MockK

The most common comparison is kotest vs junit, and the honest answer is that they are not mutually exclusive. Kotest's JVM entry point is io.kotest:kotest-runner-junit5, which means the engine runs on the JUnit platform. JUnit 5 contributes the platform and its own extension model; Kotest contributes matchers, spec styles and property testing on top of it. A migration from JUnit to Kotest is therefore incremental: existing JUnit tests keep running in the same test task while new specs are written in Kotest.

MockK answers a different question. It is a mocking library for Kotlin, and Kotest is not primarily a mocking tool; the topics list covers assertions, matchers and property testing, not test doubles. Teams commonly use both, and comparing them as alternatives misses that they occupy different layers of a test suite.

Property based testing is where Kotest has no direct JUnit 5 equivalent. kotest-property is a dedicated module for generators and shrinking, a style of testing where you assert an invariant and let the framework search for counterexamples. JUnit 5 users typically reach for a separate library to get that, which is one more integration to maintain.

Maintenance cadence, licence and upgrade cost

The repository is not archived, and the last push to the default branch was on 2026-09-20, which is recent enough that the project is being worked on. The release history shows patches roughly monthly through mid-2026, and the CHANGELOG.md at the root plus the GitHub releases page are the documented upgrade references; the README explicitly points readers to the changelog when upgrading.

The licence is Apache-2.0, which permits commercial and closed-source use and requires that the licence and notices be preserved. That is a permissive arrangement with no copyleft obligation on your own code. This is a description of the licence identifier, not legal advice; a legal review is the right place to confirm obligations for your distribution model.

The upgrade cost is tied to the module split. Because the artifacts version independently in principle, a partial upgrade that moves kotest-runner-junit5 but not kotest-assertions-core can produce mismatched behaviour. kotest-bom exists to remove that class of problem by pinning every module to one version, and using it is cheaper than reconciling versions by hand later.

Editorial conclusion

Kotest fits Kotlin teams that want matchers, property testing and a choice of spec styles in one Apache-2.0 dependency set, and it fits multiplatform projects that already build against the JVM, JS or native targets. It is the wrong tool for a Java-only codebase with no Kotlin source, and a poor fit for a team that will not adopt Gradle or Maven coordinates and instead wants a plain command line runner. Before adopting, verify the current version of io.kotest:kotest-runner-junit5 on Maven Central, confirm the artifact you need exists for each target you build, and read the changelog for the jump to your chosen line.

Frequently asked questions

Official sources

1. kotest/kotest on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases