Figure out if we want automatic cancelation at the end of a test block

[JakeWharton]

Right now a test block requires that you cancel, cancel and ignore events, or consume a terminal event before the test block will complete successfully. This creates a very explicit script that details the lifecycle of the underlying collection operation, but with infinite flows (such as those from SQLDelight or presenters) it means every block ends with cancel().

What are the implications of automatically canceling? We would still validate all received events were consumed. cancel() would almost certainly still be an API so that you could explicitly control it. We could rename cancelAndIgnoreRemainingEvents() to just ignoreRemainingEvents().

[Egorand]

There should definitely be a more lenient way to test hot Flows, where validating events captured thus far and ignoring the complete event are enough to make the test pass. Having to cancel() the Flow manually in every test does feel annoying.

[JakeWharton]

Its intent is to be explicit. I'm sure someone testing finite flows would remark that having to consume the completion event is also annoying, but it means that if you erroneously make your stream infinite then it would be caught.

[kevincianfarini]

Maybe this is too simple, but would testCancelling be undesirable?

[JakeWharton]

I wouldn't want to ship that. Someone can write that extension themselves for their own codebase.

fun <T> Flow<T>.testCancelling(body: FlowTurbine<T>.() -> Unit) {
  body()
  cancelAndIgnoreRemainingEvents()
}

[mhernand40]

With Coroutines 1.6.0 and Turbine 0.7.0, I am seeing that cancellation is not required when testing Hot Flows. The following tests all pass for me:

class TestHotFlowWithoutCancellingFlowTurbine {
    @Test
    fun `test runTest + StandardTestDispatcher`() = runTest(StandardTestDispatcher()) {
        testHotFlowWithoutCancellingFlowTurbine()
    }

    @Test
    fun `test runTest + UnconfinedTestDispatcher`() = runTest(UnconfinedTestDispatcher()) {
        testHotFlowWithoutCancellingFlowTurbine()
    }

    @Test
    fun `test runBlockingTest`() = runBlockingTest {
        testHotFlowWithoutCancellingFlowTurbine()
    }

    @Test
    fun `test runBlocking`() = runBlocking {
        testHotFlowWithoutCancellingFlowTurbine()
    }

    private suspend fun testHotFlowWithoutCancellingFlowTurbine() {
        val flow = MutableSharedFlow<Int>()

        flow.test {
            flow.emit(0)
            assertEquals(0, awaitItem())
        }
    }
}

Is this intended? If not, should I file a separate issue for this?

[JakeWharton]

Yes. That is surprising as the collector should stay active and thus test should not return.

[mhernand40]

Sorry, "Yes" as in this is intended or "Yes" as in I should file a separate issue? I am pretty sure you meant the latter but I just want to be sure. 🙂

I have filed #90.