:mega: :mega: :mega: kotlinx.coroutines 1.6.0 is here! - Brand new `kotlinx-coroutines-test` modul...

# coroutines

[Vsevolod Tolstopyatov [JB]]

📣 📣 📣 kotlinx.coroutines 1.6.0 is here!

• Brand new kotlinx-coroutines-test module with reworked API and multiplatform support
• CoroutineDispatcher.limitedParallelism and elastic <http://Dispathers.IO|Dispathers.IO>
• Out-of-the-box support of new K/N memory model
• CopyableThreadContextElement for mutable context elements
• And a lot of improvements and bug fixes: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.6.0
We also have a blogpost and

what’s new▾

video with additional details, examples and explanation

[Vsevolod Tolstopyatov [JB]]

native-mt version is also here, and this is the last major version of coroutines with the support of native-mt builds: https://github.com/Kotlin/kotlinx.coroutines/issues/462#issuecomment-999557659

[Orhan Tozan]

So this is using Kotlin 1.6? Didn't Kotlin 1.6 have a breaking bug? Why not Kotlin 1.6.10?

[russhwolf]

So is the expectation that by 1.7, most of the K/N community will have migrated to the new memory model? I'm a little surprised native-mt wouldn't be supported for one more release cycle in case people are slow to move over.

[Dmitry Khalanskiy [JB]]

See https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-test/README.md#virtual-time-support-with-other-dispatchers
Turbine launches the collect of this flow in Dispatchers.Unconfined, which is not linked to `kotlinx-coroutines-test`: https://github.com/cashapp/turbine/blob/trunk/src/commonMain/kotlin/app/cash/turbine/FlowTurbine.kt#L86
So, the timeout runs with delay-skipping, whereas the flow body does not.

I would suggest turning off the timeout, as our test framework will also fail if the system hangs.

@Test
    fun myTest() = runTest {
        flow {
            yield()
            delay(10.milliseconds)
            emit(Unit)
        }.test(0) {
            assertEquals(Unit, awaitItem())
        }
    }

[Dmitry Khalanskiy [JB]]

Though this wouldn't solve most problems with how test is typically used. I think the long-term solution would be to ask Turbine to allow passing a dispatcher in which the flow should be collected. If this is done, passing an UnconfinedTestDispatcher there would make the flow aware of the delay-skipping.

[Paul Woitaschek]

Can you post your ideas here?
https://github.com/cashapp/turbine/issues/71

[Paul Woitaschek]

That seems on the roadmap already

[Dmitry Khalanskiy [JB]]

Nah, it's the opposite, actually. They're running the timeout just fine (and if they implement the change, it's also going to be fine), it's the flow's body that should run on a different dispatcher.

[Dmitry Khalanskiy [JB]]

Here's the relevant issue: https://github.com/cashapp/turbine/issues/42 I'll continue there.

[Paul Woitaschek]

It’s probably good if you communicate directly there as these two libraries closely belong together

[Dmitry Khalanskiy [JB]]

I somehow missed the obvious solution that is not very verbose: https://github.com/cashapp/turbine/issues/42#issuecomment-868681072
So,

@Test
    fun myTest() = runTest {
        flow {
            delay(10.milliseconds)
            emit(Unit)
        }.flowOn(UnconfinedTestDispatcher(testScheduler))
        .test {
            assertEquals(Unit, awaitItem())
        }
    }

[Paul Woitaschek]

So should that be the default?