I’ve written already about mocks in Kotlin. In that post, I was using Atrium to write my assertions. Since then I gave Strikt a try, which is another cool little library. Meanwhile I was using AssertJ at work, so I’ve had the opportunity to experiment quite a bit lately!

There are two little tricks ( KotlinTapas, if you will) that I find worth sharing:

Assertions for data classes

Custom assertions

Assertions for data classes

Our functions receive and return data classes. That means that our tests will often expect as a result a particular instance of one such class. For the assertions, we started by using isEqualTo to compare the whole instance.

this approach becomes a problem as your classes gain in complexity. Maybe they contain other entities, or there are lists or maps involved. Generating a proper instance to make isEqualTo happy ends up being a lot of work.

Instead, we want to check just some of the properties. I prefer to avoid multiple assertions in one test, but in this case I see it as unavoidable. This is the solution I use for AssertJ, followed by the one for Strikt

I really like the compactness of the Strikt solution. To be fair, we could compress the AssertJ one with apply . But I much prefer the second one.

What about the error message? A drawback of having different assertions is that you get an error message lacking in context:

Who can make sense of that without looking at the test in detail? Luckily, our solution offers a much more meaningful message:

Much better, isn’t it?

Custom assertions

A way of making assertions say more is to expand them according to our needs. For example, I have been playing with Arrow a lot lately (which on its own can be an endless source of blog posts I believe). I am getting away from using exceptions as much as I can, instead using the Either datatype. Or Monad, it’s not like I really know what I’m talking about.

In any case, I have a repository with a function that I want to test.

fun find(id: Int): Either<Int, RecipeDetails>

I’m calling the method, and want to assert that I got a valid return ( Either.Right ). Then I want to check some of the properties of the output:

this code is a bit unsatisfying. I have to check if the value is a Right value, convert it, and then get the actual content before I can start asserting. Luckily for us, Strikt allows you to write custom assertions that are perfect for a case like this. After hitting my head against the typing for a while, I arrived at this helper:

which I use then like this:

not a huge change. However, it increases the readability of that little snippet and makes the intentions behind it clearer. I like code with good intentions.

The same can be done for the Option datatype:

Why, though?

What did we accomplish? Two things, in my mind: