Davis Mohar
03/25/2022, 2:56 PMtimed()
function that I'm trying to mock:
interface Metrics {
suspend fun <T> timed(name: String, f: suspend () -> T): T
}
So you would think you could mock that with:
val mockMetrics: Metrics = mockk()
val funSlot = slot<suspend () -> Either<Nothing, Transfer>>()
coEvery { mockMetrics.timed(any(), capture(funSlot)) } coAnswers { funSlot.captured() }
mockMetrics.timed("metricName") { foo() }
That is only sometimes correct, which is the worst kind of correct. Depending on how I run the tests (kotest tests running on gradle), the test containing this mock will pass sometimes. When it fails, we get a
io.mockk.MockKException: no answer found for: Metrics(#3).timed(mmp.process.transfer.latency, continuation {}, continuation {})
which implies that timed
takes three arguments. I believe that's expected behavior, based on how suspend functions compile behind the scenes. But that also implies that our installed answer on our mocked timed
call complied differently -- but only sometimes. Has anyone dealt with behavior like this before? My current workaround is just writing a custom little MockMetrics class instead of using mockk for it.Alder
03/29/2022, 11:40 PMdepending on how I run the testsare there particular run strategies that always fail vs others that succeed?
Davis Mohar
03/30/2022, 1:12 AMinstrumented processor returns the result
)
And the test fails in the following scenarios:
• running the entire module using the 'kotest' IntelliJ plugin (see picture: modules: xxx.core.test
) -- this is the super weird one to me
• running ./gradlew test
It smells like a test runner issue to me, but the fact that running the tests differently using the kotest plugin produces different results is baffling meAlder
03/30/2022, 1:23 PMslot
?Davis Mohar
03/30/2022, 1:25 PM./gradlew test
or run the entire module with the kotest plugin