hi guys, anyone is a Molecule fan? I'm in trouble writing a test, basically I have modelled a presenter with an initial State

Content

and once it receives the

LoadTracks

event it produces 2 recompositions:

> Content
> Loading
> Content (or Error in case of failure)

I'm testing the Failure scenario, but it seems that the

Loading

state is not emitted. It seems an issue related to the test, because the application works properly. Any suggetions? This is my Presenter:

class CatalogPresenter @Inject constructor(
    private val mediaRepository: MediaRepository,
) : AbsPresenter<CatalogState, CatalogEvent>() {

    @Composable
    override fun models(events: Flow<CatalogEvent>): CatalogState {
        val state = remember { mutableStateOf<CatalogState>(CatalogState.Content()) }

        LaunchedEffect(Unit) {
            events.collect { event ->
                when (event) {
                    is CatalogEvent.LoadTracks -> loadMedia(state)
                }
            }
        }

        return state.value
    }

    private suspend fun loadMedia(state: MutableState<CatalogState>) {
        state.value = CatalogState.Loading
        state.value = mediaRepository.listMedia().fold(
            ifLeft = { err -> CatalogState.Error(err.message ?: "") },
            ifRight = { list -> CatalogState.Content(list) }
        )
    }

}

And this is my test:

private fun testPresenter(events: Flow<CatalogEvent>): Flow<CatalogState> = moleculeFlow(
        mode = RecompositionMode.Immediate
    ) { CatalogPresenter(mediaRepository).models(events = events) }

    @Test
    fun `Test loading upon failure`() = runTest {
        // Given
        val events = flowOf(CatalogEvent.LoadTracks)
        coEvery { mediaRepository.listMedia(any()) } returns Either.Left(AppException.GenericError)

        // When
        testPresenter(events).test {
            // Then
            assertIs<CatalogState.Content>(awaitItem())
            assertIs<CatalogState.Loading>(awaitItem())
            assertIs<CatalogState.Error>(awaitItem())

            coVerify { mediaRepository.listMedia(any()) }
        }
    }

What is it that fails here? Also a bit hard to reason about when you start construct the presenter with an events flow which is already pre-filled before the test even starts. Wouldn’t it be nicer to start the presenter, assert the initial state, then pass the event in there, and then continue your assertions?

Yes, good questions, I tried both: • passing a flows of event • emit them into a channel like this

val events = Channel<CatalogEvent>()
coEvery { mediaRepository.listMedia(any()) } returns Either.Left(AppException.GenericError)

testPresenter(events.receiveAsFlow()).distinctUntilChanged().test {
    // When
    awaitItem() // skip initial
    events.send(CatalogEvent.LoadTracks)

    // Then
    assertIs<CatalogState.Loading>(awaitItem())
    assertIs<CatalogState.Error>(awaitItem())

    coVerify { mediaRepository.listMedia(any()) }
}

but issue is the same

assertIs<CatalogState.Loading>(awaitItem())

fails because the actual is

Error

Expected value to be of type <...CatalogState.Loading>, actual <class ...CatalogState$Error>

You are doing a back to back change of the state. For the state change to actually be emitted, there should be some things done, like the recomposition clock to tick etc. I don’t know the full details enough myself tbh, but there’s articles etc of how this works. Now you are definitely using the Immediate clock here, so you may expect this to happen immediately, but I’ve always found this to be super hard to reason about, and that’s not super good for tests! Your solution here is to stop using mocks 😊 Make a fake implementation of MediaRepository, and let it suspend while

listMedia

is evaluating. Then assert that it’s loading, then let

listMedia

return the thing, then assert again. A quick example I’ve found here https://github.com/HedvigInsurance/android/blob/9b0270cbc79983d8cd408ba6b250a3391c[…]edvig/android/feature/profile/settings/SettingsPresenterTest.kt, you do your assertion, then you let the service to actually respond to the call (here’s the test implementation) and then you assert when you know the response is back. Nice and simple

I'll give a try tnx

You changed the presenter functionality quite a lot. Dot you want the network request to be a side effect of changing the state to loading? Now if you already got a loaded state and you want to refresh for example, you're gonna make your UI go back to the loading state, only then to trigger this side effect. But that'd look jarring for the UI. You say "I invalidate the state adding Loading and Content in the same tick" but why should you change your production code to not do this, only because your test isn't written properly to handle such scenarios?

Yes good point, probably, I miss some knowledge about how molecule works, because the problem seems not to be on the Test or on the mocking/fake repo doesn't solve anything. The cause is mainly related on how the state is invalidated. I'll continue to investigate on it, a good and struggle way to learn molecule, but I didn't find many good articles about that, and the examples are too simple

But what is the problem in the first place? The initial behavior was correct. Se the state as Loading, then wait for the repo to respond with something, then set the state to the new thing. For production you definitely don’t care if this is happening on the same frame, in fact if it did that’s even better, you don’t introduce any artificial delay for no reason. Then for the test, you got the tools at your disposal to emulate whatever scenario you want. And in my links above I show how you can emulate the exact scenario of setting to loading, then the backend responds, then you check on the state again. I would argue that in your test, where the repo responded 100% instantaneously, the expected behavior is in fact for the state to never see the

Loading

state. So I feel like you’re trying to solve an issue that does not exist, only because you don’t want to have more control over how your test runs?

Ok, so something is not 100% clear to me, why the

Loading

state should not be emitted if the repo answers instantaneously. Because in my test I would like to have the control of states even if the repo answer sin 0 or 2000ms. this should not impact the unit test.