Kotlin Assertion Libraries Conclusion

— Introduction — AssertJ — Strikt — AssertK — KoTest Assertions — Atrium — Kluent — Conclusions —

Conclusions and Recommendations

After taking a good look at the various Kotlin assertion libraries this final blog post will draw our conclusions from our findings regarding what we have learned. While the previous entries have largely attempted to deliver factual information about the libraries’ style, features and development status this last chapter will be all about our own opinions – what we liked, what we didn’t like and what we ultimately recommend.

This entry constitutes a final and opinionated summary – it intentionally does not contain any examples or detailed explanations. We assume you have read the previous entries in the series that serve as a foundation for our opinions.

Strikt

Directly referencing AssertJ as an inspiration you can infer what you can expect from Strikt. Contrary to our initial expectations we appreciated the more Kotlin-style options to run assertions. The easy customizing of assertions, expressive error messages as well as the comprehensive documentation were really pleasing. With several modules for additional functionality most of our use-cases where directly addressed.

The only weakness, if you can even call it that, is the lack of supported types compared to AssertJ or Kotest. Most of the time all your use-cases are covered, presenting itself as a nice choice for your project.

AssertK

AssertK is the conservative option. It breaks little new ground and largely follows AssertJ’s design. It makes limited use of Kotlin’s features and so offers only incremental upgrades like extension functions for custom asserts and improved lambda syntax for grouped and list assertions. The detailed and easy to read error messages of AssertK are a major plus.

Its biggest weakness on the other hand is the relatively small selection of assertions and supported types. Ultimately the question of whether AssertK is the right choice for you depends on whether you consider its emulation as AssertJ’s design to be a case of standing on the shoulders of giants or rather stagnation with the same old heavy syntax that Kotlin can easily improve upon.

Kotest Assertions

Kotest‘s philosophy is the opposite of AssertK. Instead of sticking with the well-tread design of AssertJ it embraces the options enabled by Kotlin’s extension and infix functions. While the resulting syntax takes some getting used to its terseness and simplicity has a way of growing on you.

Kotest Assertions is easy to extend and offers the largest number of assertions and supported types, second only to AssertJ itself. Its only real downside it that its error messages can – occasionally – be difficult to read. However, all in all Kotest Assertions is a great choice for your Kotlin projects.

Atrium

Of all the libraries we have looked at Atrium is the most complicated. Both its syntax and documentation are reminiscent of the kind of infamous Scala code where the arcane type signature is longer than the actual implementation. And while this description may be attractive to some, we see nothing that would make up for this degree if complexity. The heavy feature syntax is a more complicated version of property access, the documentation recounts implementation details meant for developers instead of users and the number of supported assertions and types is intentionally kept small and static, with additions only being added due to explicit feature requests. Only the detailed error messages can be counted as an advantage. So in our estimation the answer to whether you want Atrium in your project is “probably not”.

Kluent

With Kluent it strongly depends on what you expect from a Kotlin assertion library. Its premise is to be simplistic and it does not aim to do anything fancy. If you just need fluency and basic type support then you might be happy with Strikt. For us this was not nearly enough, therefore it rapidly fell in our personal ranking.

The biggest caveat is that you cannot even see what the current state of development is and the dissonance to the documentation. Additionally the hard dependencies to Junit4 and Kotest require you to manually exclude them if you do not need them. The removal of Junit4 even breaks some functionality. This library very much feels like a “for personal use” project to us.

Our Pick for a Kotlin assertion library

Our current choice for a Kotlin assertion library is Kotest Assertions! Provided you use Kotest you already get the core as transitive dependency. But it works just as well for every other test runner (like JUnit). If you only need a smaller/simpler library we would recommend Strikt.

— Introduction — AssertJ — Strikt — AssertK — KoTest Assertions — Atrium — Kluent — Conclusions —