I just added a dependency which pulled in slf4j and slf4j-android into my kotlin android project. It looks like JvmMockKGateway.Companion logs from its init {} block, and if slf4j is present, it uses slf4j. And with the slf4j-android binding present, slf4j will call into android.util.Log, which will raise an assertion error if it’s called from a unit test, when unmocked, resulting in an exception, resulting in a NoClassDefFoundError for JvmMockKGateway.

assuming you're in an Android unit test, I don't see why this would result in NoClassDefFoundError - it should be running with a stub Android API

So, I’ve been trying to avoid turning on isReturnDefaultValues, because their own documentation warns you away from it

I wouldn't consider it mockk bug - seems like anything that logs would have problems in this setup.

yeah. but what I mean is, it seems unsafe for mockk to be logging from its class initializer (isn’t it?)

I don't agree - loggers should generally not throw. if an exception is recoverable it should be handled inside the logger and if it is not recoverable then the application should not continue

I agree that they shouldn’t

any dependency that brings in a specific slf4j binding is broken :(

100% agree

IMO it isn't a configuration that MockK should be expected to handle, and you should still have other workarounds

Ahhh --- thanks for pointing me in that direction!