Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Coroutines in Espresso #462

Open
seadowg opened this issue Nov 20, 2019 · 4 comments
Open

Support Coroutines in Espresso #462

seadowg opened this issue Nov 20, 2019 · 4 comments

Comments

@seadowg
Copy link

seadowg commented Nov 20, 2019

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
Copy link
Author

seadowg commented Dec 11, 2019

Any word on this?

@JoseAlcerreca
Copy link
Collaborator

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.

@seadowg
Copy link
Author

seadowg commented May 13, 2020

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?

@TWiStErRob
Copy link
Contributor

@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?

Zemotacqy pushed a commit to Zemotacqy/android-test that referenced this issue May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants