Test passes for 'runBlocking' but fails for 'runBlockingTest'

The test below passes when runBlocking is used but fails with runBlockingTest.

sealed class Event {
  data class A(val id: Long) : Event()
  data class B(val id: Long) : Event()
}

class Test {
  @Test fun blocking() = runBlocking {
    val events = flowOf(Event.A(0), Event.B(0)).broadcastIn(this).asFlow()

    val a = events.filterIsInstance<Event.A>().map { "$it" }
    val b = events.filterIsInstance<Event.B>().map { "$it" }

    val strings = flowOf(a, b).flattenMerge().toList()

    Assert.assertEquals(strings, listOf(Event.A(0), Event.B(0)).map { "$it" })
  }

  @Test fun blockingTest() = runBlockingTest {
    val events = flowOf(Event.A(0), Event.B(0)).broadcastIn(this).asFlow()

    val a = events.filterIsInstance<Event.A>().map { "$it" }
    val b = events.filterIsInstance<Event.B>().map { "$it" }

    val strings = flowOf(a, b).flattenMerge().toList()

    Assert.assertEquals(strings, listOf(Event.A(0), Event.B(0)).map { "$it" })
  }
}

Events are missing from the expected result.

java.lang.AssertionError: 
Expected :[A(id=0)]
Actual   :[A(id=0), B(id=0)]

Kotlin: 1.3.50. Coroutines: 1.3.2.

[fblampe]

Are there any news or a timeline for this? Removing delays in tests via RunBlockingTest would be very helpful, but only if it works reliably without a lot of extra coding.

[RBusarow]

Hmmm, but how does that work for runBlocking?

If I need to have the same dispatcher, then should I encapsulate all Dispatchers to keep them under my control? It looks like I’m gonna need to add a lot of dependencies for every case I need to use coroutines, my fear is to couple too much our code into the way coroutines works.

Yes, that’s a common complaint. The typical solution is to wrap all references up into a single injectable object like so:

interface DispatcherProvider {
  val main: CoroutineDispatcher
  val mainImmediate: CoroutineDispatcher
  ...
}

A different solution is in the works for #1365 , where you’ll be able to use Dispatchers.setDefault(...) to manipulate that singleton in lieu of all the injection, but now you’re manipulating a shared state in your testing.

You can do things to mitigate this issue, such as only specifying the dispatcher when it’s really necessary (for instance immediately before doing I/O in a repository). Typically, you shouldn’t need to specify the dispatcher as the main thread is typically capable of much more than we give it credit for. Also, if you’re using a third party library with coroutine support for I/O, such as Room or Retrofit, they already use their own dispatchers internally, so switching before calling a suspend function in their library is just wasteful.

Not to plug, but a final option would be my not-quite-complete little library DispatcherProvider, which uses the CoroutineContext itself to hold the interface described above. This way, the dispatchers are set upon creation of a CoroutineScope and are accessible from any coroutine or suspend function via the coroutineContext property.