Search code examples
unit-testingkotlinlanguage-designtest-double

What is the Kotlin philosophy of test doubles?


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?


Solution

  • 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: