https://kotlinlang.org logo
Join Slack
Powered by
What is the recommend way to use `runBlocking` for...
# multiplatform
b
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.
j
I thought 
runBlocking
exists for all except JS
Indeed in my lib I have it
c
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
➕ 1
b
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,
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?
j
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
j
I have a doubt, why the coroutines native artifact is not, by default, the native-mt?
it will be merged some day?
j
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/
👀 1
b
@John O'Reilly Hmmm, does that mean that I need to completely rewrite code to avoid the whole frozen mutability exception business?
j
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"
b
Ok. But for now we'll have to deal with object freezing if we want to use Kotlin 1.4 and Ktor?
j
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
b
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.
c
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
b
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.
c
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
b
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. 😉
j
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
We use something like that:
Copy code
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) }
}
then in the testcases you can override whatever you want:
Copy code
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
}
So a test setup looks like:
Copy code
private val coroutineHelper = TestCoroutineHelper()

	private lateinit var presenter: BatteryStatusPresenter

	override fun setUp() {
		super.setUp()
		presenter = BatteryStatusPresenter(
			view, coroutineHelper, soundPool, context, appHelper, intentFactory)
	}
b
@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?
j
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.
but from 
@Test fun myTest() {  someClass.callToSuspendFunction() }
doesn't work of course, as you cannot directly call a suspend function
b
So how would you write that on the JVM then? By using 
launch
or something in your suspend fun?
j
@Test fun myTest() { runBlocking { someClass.callToSuspendFunction() } }
with runblocking you can call the suspend fun
b
And using your setup will make sure that this is all run always on 
Dispatchers.Unconfined
?
j
Yes, if you use a thing like coroutine helper to switch out all your dispatchers with an unconfined dispatcher during tests it should work
b
Cool. Interesting
j
apparently there is also this test coroutine dispatcher
13 Views
Open in Slack
PreviousNext
Powered by