coroutines + espresso In `Fragment.onCreate` am c...

# android

[Marko Novakovic]

coroutines + espresso

In Fragment.onCreate am calling lifecycleScope.launch { ... }. … 😄 is something I need to verify but espresso test is not waiting for it so it’s not deterministic, sometimes it fails and sometimes it passes.
how can I make espresso test to wait for … inside launch {} to finish? is IdlingResources what am looking for?

ideally I would move all of that into ViewModel and not deal with it in the Fragment but currently it’s not up to me 😕

[gildor]

It’s a usual problem with asyncronous calls on your UI
We usually handle it in a “fair for user” way, if something is happening on UI it should show loader, and if loader is visible, espresso will automatically wait. Though it’s easier to say than implement

So anyway, it helps to test in UI tests what can be correctly tested by user

[Marko Novakovic]

I see what you are saying. my situation is a bit different that that:
lifecycleScope.launch {}. is triggering analytics/tracking so that’s not something user has to know about. because of the state of the code there are suspending functions that have to be called as part of that

[gildor]

a bit strange to have suspend function for analytics.
And agree, it indeed looks like must be moved and tested as part of VM

The direct solution is to use a bit of polling and wait for this event N seconds.
Also if you can provide fake component where you have this suspend function, which returns immediately, it will not cause delay, so it should be more stable

[Marko Novakovic]

thanks. it’s a bit tricky as of now, I will see what I can do tho

[Marko Novakovic]

launch(Dispatchers.Unconfined) solved it but am not happy about it

[gildor]

lifecycleScope.launch should be also undispatched if called from main thread (because it uses Dispatchers.Main.immediate)

[psh]

On previous projects we always pushed our analytics tracking back behind an interface, and injected a stub implementation while testing. We tested that the stub was called with appropriate values during the test run, and wrote specific integration tests around the analytics tracker as a separate effort.

Would a similar strategy work here for you?

[Marko Novakovic]

thanks Paul, that would work and that is kind of how this is implemented. there is some weird stuff going on and I just joined the project so am testing the water atm 😄. this is just a problem that I ran into