Skip to content
Latchkey

kotlin.test / MockK test failures and verification errors in CI

Kotlin tests use kotlin.test assertions and often MockK for mocking. In CI, failures come from real assertion mismatches, MockK verification/answer errors, or coroutine tests that depend on timing. The report names the test, the expected value, and the actual value.

What this error means

The test task fails with "kotlin.test.AssertionError: expected:<...> but was:<...>", a MockK "no answer found for" or "Verification failed" message, or a coroutine test that passes locally but fails in CI.

kotlin.test
> Task :app:test FAILED
UserServiceTest > returnsName FAILED
    kotlin.test.AssertionError: expected:<Alice> but was:<null>
io.mockk.MockKException: no answer found for: Repo(#1).findName(1)

Common causes

A MockK stub or verification does not match the call

The every { } stub is set for different arguments than the code invokes, so MockK has "no answer found", or a verify expectation does not match the actual interaction.

A coroutine/timing dependency differs on the runner

A test using real dispatchers or delays behaves differently on a slower runner; without a test dispatcher the assertion can flake or fail.

How to fix it

Stub the exact call and assert deterministically

  1. Match the MockK every { } arguments to what the code actually calls.
  2. Use coEvery/coVerify for suspend functions.
  3. Assert on the returned value with kotlin.test after the call.
Kotlin
coEvery { repo.findName(1) } returns "Alice"
assertEquals("Alice", service.name(1))
coVerify(exactly = 1) { repo.findName(1) }

Control coroutine time in tests

Use runTest with a test dispatcher so coroutine tests are deterministic on any runner.

Kotlin
@Test fun name() = runTest {
    val service = UserService(repo, StandardTestDispatcher(testScheduler))
    assertEquals("Alice", service.name(1))
}

How to prevent it

  • Stub MockK with the exact arguments the code invokes; prefer coEvery for suspend calls.
  • Use runTest and injected test dispatchers instead of real time in coroutine tests.
  • Keep tests free of wall-clock/timing assumptions so runner speed does not matter.

Frequently asked questions

What causes ""kotlin.test ..." / MockK verify failed"?
The every { } stub is set for different arguments than the code invokes, so MockK has "no answer found", or a verify expectation does not match the actual interaction.
How do I fix "kotlin.test ..." / MockK verify failed?
Stub the exact call and assert deterministically

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card