This means that you could potentially be making unwanted calls in your methods without knowing it.īut even worse than that, the relaxed methods would return null which could introduce an unintentional test scenario and report false positives. With Mockito, by default, if you didn’t stub the method of a mocked class and called it during a test, no exception would be thrown and the test would continue as normal. There are of course specific situations where you might absolutely need to (that’s why the functionality’s there), but I speak for the majority of cases. I’m of the mindset that if you have to resort to default answers for your mocks, there’s something fundamentally wrong with your test.

In this post, I’ll explain exactly what those are.

I came to realise that Mockk offers flexibility and allows better testing practices where Mockito simply falls short on. Unlike Mockito Kotlin which is an extension of Mockito to help it work better with Kotlin, Mockk was built from the ground up for mocking Kotlin classes.įor a long time, I never had a compelling reason to pick Mockk over Mockito which I was already very familiar with, that is, until this morning. If you’re not already familiar with it, Mockk is a mocking framework built specifically for Kotlin. For the longest time, Mockito has been recognised as the go-to mocking framework for Android, but more recently, Mockk has been gaining more popularity especially with the shift to Kotlin and the adoption of Coroutines.

Mockito with kotlin