Use test-specific unconfined when test scheduler is in use

[JakeWharton]

This retains the test scheduler virtual time.

Unfortunately this requires taking a dependency on the test library and also relying on unstable API.

Closes #124. Closes #118.

[jingibus]

I'm not a fan of Unconfined. But given that we're using it, this is the right thing to do.

[JakeWharton]

Yeah no one should use it... except this library. Consuming a Flow without dispatch and without needing Unconfined would be very welcome.

[jingibus]

Consuming a Flow without dispatch and without needing Unconfined would be very welcome.

Is UNDISPATCHED insufficient?

My mental model for the tool has always been something like (pseudocode):

val channel
val job = launch { flow => channel }

validate(channel) 
cleanup(channel, job)

Which is just two coroutines running in parallel.

When I'm lazy and want to sketch out a flow validation without adding the Turbine dependency, I tend to just do something like this by hand. And that works just fine. UNDISPATCHED makes certain startup scenarios easier to wire up, but I'm not aware of anything made easier by Unconfined.

[JakeWharton]

UNDISPATCHED only controls the first entry into the coroutine. Unconfined is UNDISPATCHED but for every re-entry after that first one.

Without Unconfined we can miss values while waiting on our coroutine to be resumed only to put them into a channel. This is most visible in things which conflate emissions and can receive two updates in the same stackframe.

The test to ensure Unconfined is doing its job for us is like

val flow = MutableStateFlow(0)
flow.test {
  assertEquals(0, awaitItem())
  flow.value = 1
  flow.value = 2
  assertEquals(1, awaitItem())
  assertEquals(2, awaitItem())
}

Remove Unconfined and the second awaitItem() sees only 2 and never 1.

[JakeWharton]

Added to #132 😭

[jingibus]

Without Unconfined we can miss values while waiting on our coroutine to be resumed only to put them into a channel. This is most visible in things which conflate emissions and can receive two updates in the same stackframe.

Yep, I'm aware. :(

My POV is that walking down this path leads to places like this. And I don't really like those places.

I have this wonderful set of tools in my coroutines toolbelt, and those places say "Okay, write your real code with your coroutines toolbelt, and then switch to this totally different testing toolbelt to validate it. Your testing toolbelt will let you forget about all that coroutines stuff, it just works!" And I go "Hmm, okay..." and use the testing toolbelt. But then when my code gets bold and exciting (e.g. molecule), the underlying coroutines-iness rears its head and I have to deal with it again.

[JakeWharton]

That issue is precisely what we want!

[jingibus]

It's not what I want. See discussion here. See talk here. If it is in fact what I want, I need some convincing.

The bedrock that has served me is this idea: tooling that encourages engineers to write code with an incorrect mental model will lead to confusion and errors. When I see advice like, "Oh, you just need to use UnconfinedTestDispatcher and then your test will do what you expect it do," it's hard not to see that as whitewash over easily fixed data races.

And of course, whether that tooling can even work 100% of the time is still an open question.

[JakeWharton]

It's what this library wants. Completely dropping Unconfined and the conditional we have to make to support runTest sounds great.