mockito-kotlin VS Kotest

As you can see, I create mockUsersRepository object using mock( function. Then, in setup() method, I set up this repository in such a way so that it would return a list of hardcoded values. After this, on top of everything else, I check if, for mockUsersRepository object, getUsers method was called with verify function, in the test method. It’s important to note that Mockito is a very old framework and was originally written for Java. When Kotlin appeared, it turned out that out of the box this framework can work with some limitations, which is why an extension, mockito-kotlin, was released. The example above was written with it. Another Mockito’s limitation was that it was impossible to mock final classes and static methods, and all classes are final by default in Kotlin. Currently, this is solved through mockito-inline but, before, it was a serious limitation. In respect to Java development, there was and is an alternative for Android developers, PowerMock.

In the demo project, I used junit and mockito. One thing we need to pre-learn do the unit test, that is ksp class diagram.

What's wrong with Mockito for Kotlin?

Mockito does not work correctly with Kotlin types out of the box. Spring recommends using Mockk. There is also a special module for Mockito, which adds support for Kotlin - Mockito-Kotlin.

As you might know, Advent of Code will begin this Friday! If, like me, you want to have a go at solving the puzzles in Kotlin, I would like to share with you a little library I've developed to reduce boilerplate and solve the puzzles in a test-driven approach. It is based on Kotest, a modern and Kotlin-first test framework.

Kotlin testing with Kotest and MockK

As a matter of fact, in the previous examples, we have shifted a bit away from the TDD standards in the meaning that we test not only the operability of our code, but rather check if the code runs according to certain specifications (Given/When/Then). These specifications are our tests, and the syntactic sugar in the form of the possibility to give clear names to the tests using DisplayName and the grouping of the tests by a set of similar attributes helps us clearly formulate these specifications. There is an entire family of frameworks in different languages that allow us to create such specifications: for Java it is Spock, for Ruby—RSpec, and for Kotlin—Spek and Kotest frameworks. Below, I will go into more detail about them.

I've tried so many times. SO MANY. I love the idea of mutation testing. Even chatGPT couldn't help me. It just made up fake mutation testing frameworks to try. To me, pitest is dead. kotest is not mutation testing, but it's property testing is the next best thing I have found to revolutionize your unit tests.

The extensions are not particularly useful in this scenario because the described functionality can be incorporated into the Host class. On the other hand, they flourish in test frameworks like Kotest and enable the rapid development of useful add-ons like custom matchers. Extending third-party libraries with utility functions is another prevalent use case. In the next sections, we'll zero in on this specific aspect.

We're using Kotest for our unit tests and are quite happy with it.

Basic testing in Kotlin with Kotest built for kotlin specificatlly (upcoming)

Here you are: https://github.com/kotest/kotest/issues/189