Kotest VS mockk

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

The official suggests using dagger/hilt to inject them. However, they could be static based on the static ApplicationContext. Although Dagger/hilt aids in unit testing, mockk can accomplish this easily as well by modifying bytecode during run time. As for the stability, `mockk` has 5000+ stars on GitHub and keeps renewing.

We can create it as a class as MockK is able to mock final classes.

Mockk Documentation

Mockk is a rather new framework; it was originally designed for Kotlin, although it supports Java as well. Before mockito-kotlin was released, using Mockk was much easier and beneficial for Kotlin developers, but right now both these frameworks have nearly the same set of features and similar syntax. For example, assume that our function loadUsers is no longer synchronous, but rather suspended:

You can use mockkStatic for that, see docs. Also don't forget to unmockkStatic afterwards.

WARNING: reflective-mockk is currently powered by a reflective “hack” on mockK, and is thereby subject to removal/breakage by the mockK team at any time. If you enjoy this library & want it to be officially supported, post a comment saying so on this PR: https://github.com/mockk/mockk/pull/1005.

https://mockk.io/ is great, too.

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.