Hi! I'm trying to migrate from 1.5 to 1.6 and I ha...
# coroutines
b
Hi! I'm trying to migrate from 1.5 to 1.6 and I have a question regarding
UnconfinedTestDispatcher
. Can I use
UnconfinedTestDispatcher
as a
StandardTestDispatcher
but that it does the
advanceUntilIdle
automatically for me? Am I missing something here? I know that I'll lose some flexibility but in a lot of my tests I don't need that flexibility.
s
UnconfinedTestDispatcher
doesn't really advance all coroutines until idle
What it does is to execute jobs and continuations immediately, instead of queuing them for dispatch
In most respects its behaviour is actually similar to the test coroutine dispatcher in 1.5
b
Thanks! That's close enough for my use case :)
Would it be more correct to say that the
UncofinedTestDispatcher
automatically does the
runCurrent
?
s
I think it would be best to read the docs (which are pretty thorough). My explanation is not likely to be accurate because the behaviour of these dispatchers is somewhat intricate
There is certainly some similarity with using `runCurrent`:
we ensure that the launch and async blocks at the top level of runTest are entered eagerly. This allows launching child coroutines and not calling runCurrent for them to start executing.
Maybe somebody else has a better answer than I do 🤞
❤️ 1
b
Yes, I read the documentation but as you say "the behaviour of these dispatchers is somewhat intricate" and there are so many details that I'm getting lost in them. I think that, for now, I'm happy thinking that
UncofinedTestDispatcher
is more less as an automatic
runCurrent
.
👍 1
t
Personal opinion: when I don’t need the fanciness of controlling advances, I just use
runBlocking
and no fancy dispatcher.
If you do have delays, I wouldn’t use runBlocking. I would definitely test my delays at some point. But probably in a separate test from my logic.
b
In my case I'm not even using
runBlocking
nor
run(Blocking)test
. I just need to inject a
CoroutineScope
to my subject under test. And I'm injecting
TestScope(UnconfinedTestDispatcher)
. should I inject something different? I like the idea of use
kotlinx.coroutine.test
as less as possible: 1. It is at experimental 2. Reduce the number of no-production code that is executed in my tests.
t
I usually just inject either a plain coroutine scope, or supervisorjob scope, depending on what's closer to it's expected usage
Again the trick is when you have delays
d
Ok, nevermind me, even though the test dispatcher is unconfined, I still need to advance the scheduler by hand. Sorry for the noise.