android-test icon indicating copy to clipboard operation
android-test copied to clipboard

Published 20 hours ago • verified publisher icon android

Support Coroutines in Espresso

Open seadowg opened this issue 5 years ago • 4 comments

With the deprecation of AsyncTask I'd imagine many apps are starting to look at a switch to coroutines. One outstanding problem is that (as far as I'm aware) Espresso does not have the same support for coroutines as it does for AsyncTask - as the docs say Espresso will not make assertions until "There are no instances of AsyncTask currently executing a task".

This feature has always been a massive positive for Espresso and makes TDD/BDD workflows in Android comparatively easy so the lack of coroutine support is still a large blocker for adopting them - for me at least.

seadowg avatar Nov 20 '19 11:11 seadowg

Any word on this?

seadowg avatar Dec 11 '19 10:12 seadowg

I think it's much better to have proper hooks and use DI to replace dispatchers instead of letting Espresso do magic that you might or might now fully understand.

JoseAlcerreca avatar May 13 '20 10:05 JoseAlcerreca

I think it's much better to have proper hooks and use DI to replace dispatchers instead of letting Espresso do magic that you might or might now fully understand.

I can see that. I feel like it is possible to argue that having a UI testing framework be aware of async work feels like magic that's worth having but that aside it'd be nice to think about specifically how we'd get to a place where it's possible to write stable tests in Espresso while using coroutines. Maybe there are already docs on this that I've totally missed so sorry in advance if that's the case!

In my head there are couple of things that we could do here:

  1. Swap out dispatchers for Espresso tests with a "paused" custom dispatcher that can be manipulated during tests i.e. the test can explicilty run any coroutines to finish async work.
  2. Swap out dispatchers for Espresso tests with one that integrates with Idling Resource so that Espresso is signalled when async work is done. I'm guessing IdlingThreadPoolExecutor might be destined for this exact purpose (given I can use asCoroutineDispatcher() to turn it into a Dispatcher).

Is there an opinion on which of these would be the right thing™️ to do or in your head would a completely separate route be appropriate?

seadowg avatar May 13 '20 11:05 seadowg

@JoseAlcerreca "support" doesn't necessarily mean it's on by default. It could be an extra library like recycler contrib or web.

@brettchabot what do we need to do/help with to get official documented support?

TWiStErRob avatar Mar 28 '22 17:03 TWiStErRob