Hi! I'm trying to migrate from 1.5 to 1.6 and I have a question regarding `UnconfinedTestDispatcher`...

# coroutines

[Brais Gabin]

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.

[Sam]

UnconfinedTestDispatcher doesn't really advance all coroutines until idle

[Sam]

What it does is to execute jobs and continuations immediately, instead of queuing them for dispatch

[Sam]

In most respects its behaviour is actually similar to the test coroutine dispatcher in 1.5

[Brais Gabin]

Thanks! That's close enough for my use case :)

[Brais Gabin]

Would it be more correct to say that the UncofinedTestDispatcher automatically does the runCurrent?

[Sam]

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

[Sam]

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.

[Sam]

Maybe somebody else has a better answer than I do 🤞

[Brais Gabin]

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.

[Tim Oltjenbruns]

Personal opinion: when I don’t need the fanciness of controlling advances, I just use runBlocking and no fancy dispatcher.

[Tim Oltjenbruns]

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.

[Brais Gabin]

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.

[Tim Oltjenbruns]

I usually just inject either a plain coroutine scope, or supervisorjob scope, depending on what's closer to it's expected usage

[Tim Oltjenbruns]

Again the trick is when you have delays

[dead.fish]

Ok, nevermind me, even though the test dispatcher is unconfined, I still need to advance the scheduler by hand. Sorry for the noise.