And another difference between standard and unconfined test

Question

And another difference between standard and unconfined test dispatchers which is difficult to understand for me ``` fun test = runTest UnconfinedTestDispatcher dispatchTimeoutMs = 200 val scope = this val counter = MutableStateFlow 0 counter test awaitItem shouldBe 0 scope launch counter value = 1 counter value = 0 awaitItem shouldBe 1 awaitItem shouldBe 0 ``` This code will run fine on `StandardTestDispatcher` but will time out on `UnconfinedTestDispatcher` It s not flakiness it will time out every single time so I assume it s a difference between the two dispatchers

Michal Klimczak · Answer

Of course it s a distilled problem In a real life scenario I was observing a state of a player which does something like this ```fun playSound sound Sound currentlyPlayingJob cancel currentlyPlayingJob = playerScope launch state value = Playing sound realPlayer playSound sound filePath state value = Stopped ``` and going from Stopped to Playing to Stopped again with `realPlayer playSound` being mocked `coJustRun realPlayer playSound any ` and 0 delay caused similar effect works if you add even a 1ms delay between state changes

ephemient · Answer

StateFlow is allowed to conflate values so your problem is that you are expecting something of the API that it doesn t provide

Michal Klimczak · Answer

I do understand that part I just can t understand the difference that the dispatcher makes here

Robert Williams · Answer

This is mentioned in the documentation gt Please be aware that like this is a specific dispatcher with execution order guarantees that are unusual and not shared by most other dispatchers so it can only be used reliably for testing functionality not the specific order of actions See for a discussion of the execution order guarantees

Michal Klimczak · Answer

or should I rather say which feature of `StandardTestDispatcher` causes it to register both values

Michal Klimczak · Answer

OK you re right < Robert Williams> I ve even read this before but didn t really apply it to this problem In my head it was rather about possible flakiness of the test I expected the stateflow to conflate on e g `` but it works fine If I do`runBlocking Dispatchers Unconfined ` it ll also hang forever So the unconfined dispatcher causes a coroutine to never finish I guess my question boils down to why this is the case

Robert Williams · Answer

It s just about execution order you re relying on the second `awaitItem` to be woken up between the two `counter value` calls

Robert Williams · Answer

If it s woken up after the second value change the values will be conflated and so the third `awaitItem` will hang

Michal Klimczak · Answer

hmmmm but `awaitItem ` has a default mechanism that should only wait for one second and then cancel

Michal Klimczak · Answer

but you re right that if I remove it it will finish Sooooo unconfined breaks the timeout mechanism of turbine s awaitItem

Robert Williams · Answer

I ve never heard of this 1 second timeout on turbine are there docs for this

Robert Williams · Answer

To be fair I ve actually never tried `launch`ing from inside `test`

Michal Klimczak · Answer

omg it s been removed smile <https github com cashapp turbine commit 4d96d574b8d9cf7c21bfb82410cb66692bd0a7ba>

Robert Williams · Answer

I d normally do it with fixed delays which is more verbose but feels more like a real use case

Michal Klimczak · Answer

I was totally relying on the fact that this will kick in

Robert Williams · Answer

Yeah I know they cleaned up some of this because `runTest` now times out

Robert Williams · Answer

even though they actually function slightly differently

Michal Klimczak · Answer

all this confusion from something so simple exploding head anyway thank you very much Robert slightly smiling face

Robert Williams · Answer

No problem we also had a few annoying edge cases that were relying on turbine s specific timeout behaviour