MockK vs Mockito for Kotlin Testing

Kotlin classes are final by default, suspend functions take hidden continuation parameters, and top-level functions and objects aren't ordinary Java classes. Early Mockito struggled with all of that, which is why MockK became popular in Android. Both libraries have matured, so the choice is now mostly about style.

The same test in both

@Test
fun `refresh shows error when repository fails`() = runTest {
    val repo = mockk<ArticleRepository>()
    coEvery { repo.refresh() } throws IOException()
    every { repo.observeArticles() } returns flowOf(emptyList())

    val vm = ArticlesViewModel(repo)
    vm.refresh(); advanceUntilIdle()

    assertEquals("Couldn't refresh", vm.uiState.value.message)
    coVerify(exactly = 1) { repo.refresh() }
}

@Test
fun `refresh shows error when repository fails`() = runTest {
    val repo = mock<ArticleRepository> {
        onBlocking { refresh() } doThrow IOException()      // doThrow works with checked exceptions too
        on { observeArticles() } doReturn flowOf(emptyList())
    }

    val vm = ArticlesViewModel(repo)
    vm.refresh(); advanceUntilIdle()

    assertEquals("Couldn't refresh", vm.uiState.value.message)
    verifyBlocking(repo, times(1)) { refresh() }
}

Comparison

Often better: fakes

class FakeArticleRepository : ArticleRepository {
    val articles = MutableStateFlow<List<Article>>(emptyList())
    var failRefresh = false
    override fun observeArticles(): Flow<List<Article>> = articles
    override suspend fun refresh() { if (failRefresh) throw IOException() }
}

When mocks are the right tool

• Verifying a side effect happened exactly once (analytics event, logger call).
• Third-party classes that are hard to fake and that you don't wrap.
• Simulating rare failures in deep collaborators.

Team recommendations

Common mistakes

• Mocking data classes and value types. Just create real instances.
• Relaxed mocks everywhere, which hide missing stubs and let tests pass vacuously.
• Verifying every call, which breaks tests on harmless refactors.
• Mocking the class under test.

Frequently asked questions

Conclusion

MockK offers the most Kotlin-native API, and Mockito with mockito-kotlin is equally capable for most needs. For your own repositories and data sources, fakes usually produce clearer, more robust tests than either.

Next step: find a different kind of bug in Android Memory Leaks: Causes and Solutions.