https://kotlinlang.org logo
Title
v

Vsevolod Tolstopyatov [JB]

12/22/2021, 12:47 PM
📣 📣 📣 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
:kotlin-intensifies: 15
:kotlin-intensifies-purple: 8
🎉 12
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
🎉 3
o

Orhan Tozan

12/22/2021, 2:44 PM
So this is using Kotlin 1.6? Didn't Kotlin 1.6 have a breaking bug? Why not Kotlin 1.6.10?
r

russhwolf

12/22/2021, 4:53 PM
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.
1
p

Paul Woitaschek

12/23/2021, 10:22 AM
How do I test flows with that new runTest? Turbine always runs in a timeout:
@Test
  fun myTest() = runTest {
    flow {
      delay(10.milliseconds)
      emit(Unit)
    }.test {
      awaitItem() shouldBe Unit
    }
  }
d

Dmitry Khalanskiy [JB]

12/23/2021, 10:40 AM
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())
        }
    }
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.
p

Paul Woitaschek

12/23/2021, 10:50 AM
Can you post your ideas here? https://github.com/cashapp/turbine/issues/71
That seems on the roadmap already
d

Dmitry Khalanskiy [JB]

12/23/2021, 10:52 AM
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.
Here's the relevant issue: https://github.com/cashapp/turbine/issues/42 I'll continue there.
p

Paul Woitaschek

12/23/2021, 10:55 AM
It’s probably good if you communicate directly there as these two libraries closely belong together
d

Dmitry Khalanskiy [JB]

12/23/2021, 11:01 AM
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())
        }
    }
p

Paul Woitaschek

12/23/2021, 11:05 AM
So should that be the default?