Hello, what is the best practice to implement asse...

# server

[Bence Erős]

Hello, what is the best practice to implement assertions in unittests written in kotlin? JUnit's built-in Assertions? AssertJ? Hamcrest? Kotest?

[dave]

1 vote for Strikt

[hfhbd]

I just use kotlin("test"), which is basically a JUnit wrapper on JVM and supports the same syntax on other targets too. I really like the diff viewer in IntelliJ.

[PoisonedYouth]

Kotest is my first choice. It really good works together with the diff viewer of IntelliJ and provides a native way of writing assertions.

[nfrankel]

hello 👋
are you doing kotlin, now?

[Jacob]

assertj has been adequate for me

[Marit van Dijk]

JUnit 5 has assertions, but the JUnit team uses assertj themselves to test JUnit (since they did not want to reinvent the wheel)

[Marit van Dijk]

So JUnit 5 + assertj if you're ok using Java libraries

[Klitos Kyriacou]

As you can see, there isn't a "best practice" choice at the moment. There are several options, and they're all ok to use. So don't worry about it; choose one and use it.

[nfrankel]

a bit dated but can give you some pointers
https://blog.frankel.ch/comparison-assertion-libraries/

[kqr]

or atrium 😄

[Klitos Kyriacou]

There's also this one: https://www.novatec-gmbh.de/en/blog/kotlin-assertion-libraries-introduction/ - also a bit dated, but covers a few more assertion libraries including a few that haven't been mentioned yet.

[christophsturm]

I like strikt and kotlin-power-assert. for new code is use mostly kotlin power assert

[Mikael Ståldal]

assertk maybe?

You might be asking, "If AssertJ already exists, why create another library?". It's true, assertk is very similar to AssertJ. But assertk is written in Kotlin so it has one major advantage: extension methods. This makes adding your own assertion methods far simpler.

[Jilles van Gurp]

i like kotest; they packaged up their assertions as a separate library,

[rocketraman]

@christophsturm The advantage of kotlin-power-assert over regular assertion libraries is that you just use boolean expressions for assertions rather than specialized assertion DSLs?

[christophsturm]

yes. one great thing is that you can just use the stdlib methods that you already know. like assert(users.first().email.contains("@google"))

[christophsturm]

actually its better to use orNull() and write it like this assert(users.firstOrNull()?.email?.contains("@google")) because you don’t want your assert to throw

[rocketraman]

Any downsides you've encountered with that approach vs assertion DSLs?

[wakingrufus]

+1 to assertj. Only pain point is needing to escape the as method call for assertion messages

[christophsturm]

rocketraman [3:09 PM]

Any downsides you’ve encountered with that approach vs assertion DSLs? (edited)

the only thing that I’m currently not sure about is what’s the best way to do collection asserts, I just started a discussion about it today on the powerassert github project https://github.com/bnorm/kotlin-power-assert/discussions/74

[christophsturm]

a lot of people here are recommending java assertion libs, and while I really liked assertj or fest-assert back in the java days I think an assertion dsl should be really idiomatic kotlin so a java assertion dsl lib is not what I would recommend, just like i would not want to use a java ORM in kotlin

[wakingrufus]

i think assertj has a fluent API which isn't that out of place in kotlin. I think there is a kotlin wrapper around assertj out there, that i used to use to make it a bit more ideomatic. but nowadays i mostly just write my own extension methods on top of assertj