What is the recommend way to use `runBlocking` for unit tests in a MPP for native/ios? It looks like...

# multiplatform

[bsimmons]

What is the recommend way to use runBlocking for unit tests in a MPP for native/ios? It looks like kotlinx-coroutines-core:1.4.1 doesn't include runBlocking for native.

[Javier]

I thought runBlocking exists for all except JS

[Javier]

Indeed in my lib I have it

[Javier]

https://github.com/JavierSegoviaCordoba/run-blocking-kmp

[Casey Brooks]

It won’t be accessible in the commonTest sourceset, because it’s not available on all platforms. But you can use it in iosTest, or actual/expect it manually to be used in commonTest

[bsimmons]

Yeah, I am trying to implement it as an actual in iosMain but I'm getting this weird compilation error when I use it there,

[bsimmons]

I guess version 1.4.1 is conflicting with Ktor which is using 1.4.2-native-mt. Does that mean I am forced to use the native-mt version?

[John O'Reilly]

I think the general expectation when using KMP is that you'll need to use native-mt version....there's several libraries now that depend on that

[Javier]

I have a doubt, why the coroutines native artifact is not, by default, the native-mt?

[Javier]

it will be merged some day?

[John O'Reilly]

it's hard to say.....complicated somewhat I think by statement by Jetbrains that they're working on replacement https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/

[bsimmons]

@John O'Reilly Hmmm, does that mean that I need to completely rewrite code to avoid the whole frozen mutability exception business?

[John O'Reilly]

I think most of the changes will be under the hood....but also, from that article "We plan to introduce it in a way that is mostly compatible with existing code, so code that is currently working will continue to work. Namely, we plan to continue to support object freezing as a safety mechanism for race-free data sharing"

[bsimmons]

Ok. But for now we'll have to deal with object freezing if we want to use Kotlin 1.4 and Ktor?

[John O'Reilly]

well, it depends I think on your threading/data modification setup.....in basic case where you're for example making calls in to shared code from main thread and calling say "main-safe" ktor api calls and not mutating data coming back (which should be pretty common case) then my understanding at least is that you shouldn't have to worry about explicitly freezing objects

[bsimmons]

Yeah, unfortunately, a lot of my code does modify stuff from suspend functions. To do things like caching and such. I guess I'll have to find a thread-safe way to do this.

[CLOVIS]

For caches, you probably already use some kind of lock to edit the cache (because otherwise your cache would get destroyed?) In that case, your code is probably fine

[bsimmons]

Yeah, I am already using a lock to keep the cache consistent, but now it is also getting frozen, so I don't get a chance to use the lock in the first place.

[CLOVIS]

Instead of using a lock, you could designate a thread as the ‘owner' of the cache (taking the lock == being the one running on that thread), and now you don't need to freeze anymore right? Since the cache can only be accessed by one thread

[bsimmons]

Yes, definitely possible and a good idea. Just a lot of updating just to use 1.4. I guess you can't win them all. 😉

[Joost Klitsie]

If it is a unit test, you should be able to work around this issue by using a coroutine helper class. This one you can override during test cases to use Dispatchers.Unconfined and then everything will just run concurrently and you do not need runBlocking

[Joost Klitsie]

We use something like that:

open class CoroutineHelper @Inject constructor() {
	open val mainScope: CoroutineScope by lazy { CoroutineScope(Dispatchers.Main) }
	open val mainContext: CoroutineContext by lazy { Dispatchers.Main }
	open val mainImmediateScope: CoroutineScope by lazy { CoroutineScope(Dispatchers.Main.immediate) }
	open val ioScope: CoroutineScope by lazy { CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>) }
	open val defaultScope: CoroutineScope by lazy { CoroutineScope(Dispatchers.Default) }
	open val ioContext: CoroutineContext by lazy { <http://Dispatchers.IO|Dispatchers.IO> }
	open val defaultContext: CoroutineContext by lazy { Dispatchers.Default }
	open val unconfinedScope: CoroutineScope by lazy { CoroutineScope(Dispatchers.Unconfined) }
}

[Joost Klitsie]

then in the testcases you can override whatever you want:

class TestCoroutineHelper : CoroutineHelper() {
	override val mainScope: CoroutineScope
		get() = CoroutineScope(Dispatchers.Unconfined)
	override val mainContext: CoroutineContext
		get() = Dispatchers.Unconfined
	override val ioContext: CoroutineContext
		get() = Dispatchers.Unconfined
}

[Joost Klitsie]

So a test setup looks like:

private val coroutineHelper = TestCoroutineHelper()

	private lateinit var presenter: BatteryStatusPresenter

	override fun setUp() {
		super.setUp()
		presenter = BatteryStatusPresenter(
			view, coroutineHelper, soundPool, context, appHelper, intentFactory)
	}

[bsimmons]

@Joost Klitsie Interesting. In this case, how would you actually run your @Test though? If you don't use runBlocking {} won't the test just immediately finish and not wait for the coroutine to finish first?

[Joost Klitsie]

yeah I am thinking here, I have no native target so I on my JVM target I stlil have to wrap calls to suspend functions. But after that I don't have to wait, because all the coroutines that I launch or contects that I switch will be unconfined, meaning they are running directly on the current thread.

[Joost Klitsie]

but from @Test fun myTest() { someClass.callToSuspendFunction() } doesn't work of course, as you cannot directly call a suspend function

[bsimmons]

So how would you write that on the JVM then? By using launch or something in your suspend fun?

[Joost Klitsie]

@Test fun myTest() { runBlocking { someClass.callToSuspendFunction() } } with runblocking you can call the suspend fun

[bsimmons]

And using your setup will make sure that this is all run always on Dispatchers.Unconfined?

[Joost Klitsie]

Yes, if you use a thing like coroutine helper to switch out all your dispatchers with an unconfined dispatcher during tests it should work

[bsimmons]

Cool. Interesting

[Joost Klitsie]

https://craigrussell.io/2019/11/unit-testing-coroutine-suspend-functions-using-testcoroutinedispatcher/

[Joost Klitsie]

apparently there is also this test coroutine dispatcher