Atrium: a multiplatform expectation library for Kotlin

One assertion library across the JVM, the browser and Android

Atrium is an open-source multiplatform expectation and assertion library for Kotlin, with support for the JVM, JS and Android. That combination is the reason to look at it. A Kotlin team with a shared module, a backend and a browser target usually ends up with two assertion libraries and a set of expect and actual declarations to keep the tests compiling on every target. Atrium's answer is one library that compiles everywhere, published to Maven Central. The design goals stated in the README are narrower and more useful than the word assertion suggests. It is designed to support multiple APIs, and it focuses on helping developers understand what went wrong while preventing common pitfalls. The project was inspired by AssertJ at first, and the README says plainly that it moved on from there, providing more flexibility, features and hints.

The API style is the first decision you make

Atrium is designed to be extensible as well as configurable, and the repository layout shows how much of that is a product decision rather than a library convention. The apis/ directory holds the different API styles, bundles/ holds the packaged artifacts such as the fluent one, logic/ holds the shared implementation, translations/ holds the message resources, and samples/ contains js, jvm and multiplatform examples. The choice of API style is therefore a real choice made at the start, and the README has a whole section on it. The documentation also covers how to use your own expectation verb, and how to use your own components, which is a level of control that most assertion libraries do not offer. If your team has strong opinions about how an assertion should read, that is a feature here rather than a quirk.

Adding Atrium through Maven Central

Atrium is published to Maven Central under the group ch.tutteli.atrium, and the artifact most projects want is atrium-fluent. The README gives the requirements as Kotlin 1.4, JVM 11, and the JS IR backend, and it notes that support for the legacy JS backend was dropped with Atrium 1.2.0. For a Kotlin 1.5 or newer project on any target, the dependency is added like this:

repositories {
    mavenCentral()
}
dependencies {
    testImplementation("ch.tutteli.atrium:atrium-fluent:1.2.0")
}

In a multiplatform project the same dependency goes into the common test source set, and the README notes that you do not need to add it to specific targets such as jvmTest because that is done automatically:

kotlin {
    sourceSets {
        val commonTest by getting {
            implementation("ch.tutteli.atrium:atrium-fluent:1.2.0")
        }

The common source set is the point of the exercise, since a test written once in commonTest then runs on every target the module builds for.

Feature extractors, arbitrary features and subject extraction

The API is built around the idea of a feature, which is what an expectation looks at. The README documents feature extractors for properties and methods, arbitrary features, and subject extraction. Subject extraction is the mechanism that lets a single expectation function work on the subject it is given rather than on a fixed type, which is the answer to the question the FAQ raises about expectation functions not being available for subtypes. The practical effect is that a helper you write once can accept anything and still report something meaningful. This is the part of the design that goes beyond the AssertJ inspiration, and it is what makes the library attractive for teams that want their own domain-specific expectations rather than a long list of built-in ones.

Soft expectations, exception expectations and reasons

Three features shape how failures are reported. Soft expectations let a test collect several failures before giving up, which the FAQ addresses by explaining that Atrium does provide something like AssertJ's soft assertion, with its own approach rather than a copy. Expect an exception covers the common case of asserting that a call throws, and the attaching a reason section covers the practice of adding context to a failed expectation so the report says why the assertion mattered. These three are small features on their own, and together they are most of what makes a failing test readable in a large suite, which is the stated focus of the project.

Writing your own expectation functions and your own verb

The extensibility claim is the one to test before you commit. The README documents several ways to extend Atrium: boolean based expectation functions, throwable based expectation functions, and functions composed from those, then enhanced reporting for those, and your own sophisticated expectation builders, on top of a section on writing your own expectation verb and a section on your own components. The stated design is that you can extend it with your own expectation functions, customise reporting, or even replace core components with your own implementation. That is a larger surface than most libraries promise, and it is where Atrium differs from a drop-in assertion helper. The cost is that you now own the behaviour of the reporting layer in your project, and the benefit is that a failure message can be phrased in the vocabulary of your domain.

Where the version numbers and the JS backend leave you

Two practical details decide the version you install. First, the README on the main branch is explicitly a sneak peek at the next version, and it says so in a warning, pointing to the README of the corresponding release or git tag, with 1.2.0 named as the latest version. The repository carries 1.3.0 alpha tags alongside the 1.2.0 release, so a project that installs by tag or by snapshot can end up running a preview. Second, the platform requirements have a hard edge. The JS IR backend is required, and legacy support was dropped with 1.2.0, so a project still on the legacy JS compiler cannot use the current release. The repository also keeps CI workflows for quality assurance and a coverage badge, and the last push to the repository was on 2026-10-19, so the tree is being worked on even where the published version moves slowly.

Where Atrium is the wrong choice

Two boundaries are clear. The first is the licence. Atrium is released under the EUPL 1.2, and the badge in the README points to the EUPL text itself. That is a copyleft-style licence, and it is a different set of obligations from the MIT or Apache licences that most assertion libraries carry, so an organisation that standardises on permissive dependencies has a decision to make here rather than a formality. The second is scope. If your test suite is a single module on a single platform and the standard Kotlin test assertions cover your cases, then a multiplatform library with API styles, feature extractors, custom reporting and an extensible core buys you nothing. The alternative approach in that case is the standard assertions plus a small helper of your own for the domain-specific messages, which is less machinery and no new dependency. Atrium earns its complexity when the same tests must run on the JVM, in JavaScript and on Android, or when the failure output of your organisation has to match a house style.

Editorial conclusion

Atrium fits Kotlin teams that write tests once and run them on the JVM, in the browser and on Android, and that want an assertion library whose failure messages explain what went wrong rather than only what was expected. It does not fit a project that needs the standard Kotlin test assertions with no extra dependency, and it does not fit an organisation that cannot accept the EUPL 1.2 licence terms. Before adopting it, check the JS IR backend requirement, since the legacy JS backend was dropped with Atrium 1.2.0, pin the released version rather than the alpha tags, and read the documentation at docs.atriumlib.org, where the main branch README is explicitly a preview of the next version rather than the documentation for what you install.

Frequently asked questions

Official sources

1. License: EUPL-1.2
2. Project website
3. README
4. Releases
5. robstoll/atrium on GitHub