How are you testing `StateFlow`? If I have a data ...

# coroutines

[Shashank]

How are you testing StateFlow? If I have a data class

data class ProfileState(val isLoading: Boolean, val userName: String?)

and I have the following states which are being emitted
1. ProfileState(true, null)
2. ProfileState(false, “John Doe”)
So how do I that I received the states in the correct order while accounting for the conflation which is done by StateFlow ?

[Javier]

Have you tried Turbine by Square?

[Shashank]

Nope but I have been using this library to collect all states. However, it fails me in case of conflation as I can receive a single conflated state instead of 2 separate states which I am expecting.

This is why I wanted to understand how to test StateFlow

[taer]

I ahve a similar test case. I kinda hacked my way in w/ a flow.onStart that unlocks a pre-locked semaphore. Then I had code that was trying to lock the semaphore. So when the flow test code starts consuming, I know the event capturing is happening. Then I think you could update the MutableState. I didn't use these libs though, I just called flow.toList() in a async job and made my assertions on them.

[taer]

that way you at least know someone is consuming the flow(and thus possibly helping missing the conflation)

[taer]

I guess you could use that lib to update the mutableState inside the test method instead. That might be cleaner

[Shashank]

I can’t help but wonder if there is a simpler solution. If we are needing to jump through so many hoops then we might be doing something wrong 🤔

[taer]

flow.test(this) {
        assertValues(ProfileState(true, null))
        doTheThingThatChangesTheState()
        assertValues(ProfileState(false, "John Doe"))        
    }

[taer]

That feels better to me(if you only have one flow)

[taer]

At least in my case, I needed the collectors to run in a different coroutine so I could tweak their inputs in the main test thread.