What is the Kotlin philosophy of test doubles?

Question

What is the Kotlin philosophy of test doubles ? With all classes and functions being sealed by default (not open ), mocking frameworks like Mockito are clearly not first-class citizens.

A lot has already been written about the problem , and also about possible solutions , but what do the designers of Kotlin have in mind for testing with doubles? Is it fakes and stubs, or should you role your own spies and mocks?

Answer 1

A great part of Kotlin's design is with Joshua Bloch's Effective Java in mind, meaning closed by default, immutability, and so on.

Therefore, these problems exist in Java as well. The solution to these problems was and is to use interfaces where possible, so you can provide test doubles, or any other implementation to your production code for that matter.

For tests, these might be mocks, or fakes, or stubs, or what have you. Bear in mind that a well-written in-memory repository for example is way easier to handle in tests than having to set up a mock for that class.

Answer 2

Frameworks like Mockito are first class citizens, including to the point where they are directly mentioned as one of the reasons for the all-open compiler plugin released in Kotlin 1.0.6 . Your references to problems/solutions are out of date and it would be nice if those authors updated their posts .

From that release announcement you will see Mockito called out specifically:

The all-open compiler plugin makes classes annotated with a specific annotation and their members open without the explicit open keyword, so it becomes much easier to use frameworks/libraries such as Spring AOP or Mockito. You can read the detailed information about all-open in the corresponding KEEP .

We provide all-open plugin support both for Gradle and Maven, as well as the IDE integration.

The plugin is available for use using the command-line compiler, IDE compiler, and from Gradle and Maven.

Other references:

• Using Mockito with Kotlin

Answer 3

In addition @nhaarman's comments, another option is Mockito-Kotlin . I like that Kotlin's classes are final by default, so the all-open compiler plugin isn't a good option for me.