Can Turbine help me test a Flow without caring about the order of events?

[DougMcTuro]

Sometimes, I have a Flow that might emit several events. I don't know what order these events will come in, or how many events there will be, but I need to verify that at least one of them satisfies a certain condition.

In these situations I find myself writing code that looks like this:

var receivedExpectedEvent:Boolean = false
val job = launch {
    foo.events.collect { event ->
        if (event is TheTypeOfEventICareAbout) {
            receivedExpectedEvent = true
        }
    }
}
foo.startTheEvents()
advanceUntilIdle()
assertTrue(receivedExpectedEvent)
job.cancel()

It would be nice if this could be condensed to something like:

foo.events.test{
    foo.startTheEvents()
    assertNotNull( awaitFirstOrNull{ event -> 
        event is TheTypeOfEventICareAbout
    })
}

Where awaitFirstOrNull waits for and returns the first item that satisfies the criteria, or returns null if all events have been consumed and none of them satisfy.

Can Turbine do that?

[JakeWharton]

There is nothing built in, but you could definitely write an extension which did this. Simply loop on awaitItem() until your condition is met and then break.

For such a function to be included in Turbine itself there's all kinds of considerations to be made. For example:

• Does the timeout apply to the whole operation or each individual await?
• How many items do we consume before we fail?
• What happens to the unconsumed items?
• How do you test for multiple conditional matches in a group of items without relying on order?

I think including such a function starts to move Turbine from being a fairly simple collector of events from a Flow and into an actual library providing assertions over a stream. And that opens us up to needing to provide myriad functions like this which I'm very hesitant to do.

One thing that might be useful is to provide more access to events which are already consumed. This would result in changing from a channel as the sole backing primitive to some other type that I suspect we need to build ourselves. But, again, I'm hesitant to make that change unless we absolutely need it.

[DougMcTuro]

That makes sense, and I understand your hesitation. Thanks for the answer!