I have a test where a flow should emit with delay, but it doesn't emit:

@Test
fun `test flow`() = runTest {
    val eventUpdateService = mockk { 
        every { subscribeToEvents() } returns flowOf(SomeEvent).onStart { delay(1000) } 
    }
    val presenter = Presenter(
        UnconfinedTestDispatcher(),
        eventUpdateService
    )
    presenter.attachView(view)
    advanceTimeBy(2000)
    verify { view.displayEvent() } // fails because the flow didn't emit
}

class Presenter(
    coroutineContext: CoroutineContext,
    val eventUpdateService: EventUpdateService    
) {

    val coroutineScope = CoroutineScope(coroutineContext)

    fun attachView(view: View) {
        coroutineScope.launch {
            eventUpdateService.subscribeToEvents().collect { event ->
                view.displayEvent()
            }
        }
    }
}

There is no code here that collects the flow here AFAICT. The flow is cold, nothing happens until some consumer collects it

The consumer is inside the tested presenter, consuming should cause a side effect. Sorry, I didn't post all relevant code.

presenter.subscribeToEvents()

is mocked to return a flow that is never used or collected, what is inside the presenter is irrelevant

You are obviously right, sorry. By trying to make my example minimal I actually made it wrong...

My guess is that the

advanceTimeBy

call doesn't affect the

Presenter

because you're passing a new

UnconfinedTestDispatcher

(which is not linked to

runTest

) to the

Presenter

instance

Yes, that's also my suspicion.

Yep. You should have access to the

coroutineContext

of the current test scope inside

runTest

, so you should pass this one directly to the presenter without creating a new dispatcher

@Test
fun `test flow`() = runTest {
    val presenter = Presenter(coroutineContext, //...)
    // ...
}

This indeed works. Thank you!

btw, creating a

CoroutineScope

from an external

CoroutineContext

seems a little odd. If the context has a

Job

then that means the caller owns the lifetime, If it doesn't have a

Job

then

CoroutineScope

factory function creates a

Job

and the

Presenter

is in charge of managing the lifetime. I generally pass in

CoroutineScope

and it's up to the caller to manage the lifetime or I pass in a specific context like

CoroutineDispatcher

that definitely does not contain a

Job

so the class can create it's own

CoroutineScope

and be in change of cancelling it.

Yes, that's a very good point. This example is obviously simplified. We don't use the

CoroutineScope

factory function itself. We have our own

PresenterCoroutineScope

which creates a

Job

and lets the

Presenter

internally manage its own lifecycle. But you are right, in this case we should only pass a dispatcher and not the whole context, including the externally created

Job

. Thank you for bringing this to my attention.

I kinda disagree (at least as a general statement). Depending on how generic a component is, it may be nice to allow users to specify other things like an exception handler or a coroutine name, not just a dispatcher. And yet you may want control over the lifecycle using

cancel()

which would be unadvisable on a user-provided scope

In production code we actually always inject in the

PresenterCoroutineScope

a

Dispatchers.Default

.

Yep it might be correct for your use case. I was disagreeing with @Nick Allen's general statement

I wonder how it works for tests though. Tests need to inject an exception handler I guess?