Hello, I had to use coroutines reactive but I ran in a strange behavior while testing. This is a min...

# coroutines

[Marco Righini]

Hello, I had to use coroutines reactive but I ran in a strange behavior while testing. This is a minimal not working example

class CoroutinesReactiveTest {

    private val dep = mock<Dep>()
    private val underTest = UnderTest(dep)

    @Test
    fun `Test someOtherMethod called`() = runBlocking {
        underTest.methodToTest().test()

        verify(dep).someMethod() // Commenting this line test passes
        verify(dep).suspendingFun()
        verify(dep).someOtherMethod()
    }
}

class Dep {

    fun someMethod() {
        println("someMethod called")
    }

    suspend fun suspendingFun() {
        delay(100)
        println("suspendingFun called")
    }

    fun someOtherMethod() {
        println("someOtherMethod called")
    }
}

class UnderTest(private val dep: Dep) {

    fun methodToTest(): Completable {
        return Completable.fromCallable { dep.someMethod() }
            .andThen(rxCompletable { dep.suspendingFun() })
            .andThen(Completable.fromCallable { dep.someOtherMethod() })
    }
}

commenting the first verify test passes

[Marcelo Hernandez]

One thing to note is that Rx’s test() is not a blocking function as far as I’m aware, so it will return immediately. However, both rxCompletable and delay() operate on Dispatchers.Default by default. So I’m wondering if somehow test() is returning immediately but your delay() is operating asynchronously by the time you run your verify() calls.

[Marcelo Hernandez]

Yes the runBlocking will wait for all suspend code to return but I don’t think it guarantees that these suspend functions return before you make the verify calls.

[Marcelo Hernandez]

I would also suggest you swap out runBlocking for runBlockingTest so that your tests do not actually delay.

[Marco Righini]

Dependency is mocked so the test doesn't depend on the implementation of the suspending function.

[Marcelo Hernandez]

Ok, but the test still ends up calling rxCompletable right?

[Marcelo Hernandez]

If rxCompletable { … } is used with all the default parameters, it will use Dispatchers.Default. Which means in your test environment, there will be thread hopping. I have had to work around this by explicitly passing in a Dispatcher which I have set up as part of my Dependency Injection graph.

// Where dispatchers is my own wrapper around static Dispatchers
rxCompletable(dispatchers.default) { … }