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

Test module shall provide ability to replace Dispatchers.IO and Dispatchers.Default #982

Open
elizarov opened this issue Feb 12, 2019 · 9 comments

Comments

@elizarov
Copy link
Contributor

This seems to be as useful for predictable tests as replacing Dispatchers.Main. See discussion in #242 and #890.

@elizarov
Copy link
Contributor Author

Note, that since Dispatchers.IO is conceptually a "special view" of Dispatchers.Default (sharing the same thread pool) we might as well just provide an ability to replace Dispatchers.Default with a dispatcher that has an API for creating such views. It would work nicely when such an API is made public (see #261)

@yigit
Copy link

yigit commented Feb 12, 2019

I think that fact (using same pool) is not very clear to average developer so I would prefer having them separate APIs to make them match the existing public API.
Unless of course kotlin provides a TestRule that does all of the requests in (#242)

something like:

@RunWith(AndroidJunit::class)
class Test {
    @Rule
    @JvmField
    val dispatchers = CustomDispatchersRule()
}

where CustomDispatchersRule
a) automatically registers to espresso (if possible), or at least implements IdlingResource interface (that is a separate artifact so taking that dependency seems to be OK)
b) provides await methods (dispatchers.awaitIdle(time : long, unit : TimeUnit)).

It could be handy for this class to receive a scheduled executor for further customization though i'm not sure if there is a clear use case for that (vs one that it can create).

@elizarov
Copy link
Contributor Author

@yigit A test rule is definitely on the radar.

@hameno
Copy link

hameno commented Jul 26, 2020

Any progress here? Wondering how I should test my code using withContext(Dispatchers.Default) while using runBlockingTest

@AOrobator
Copy link
Contributor

For now you can probably just inject your Dispatcher so that you can swap it out for TestCoroutineDispatcher in the test

@CDRussell
Copy link

I wrote about using TestCoroutineDispatcher if it's of use to you:

https://craigrussell.io/2019/11/unit-testing-coroutine-suspend-functions-using-testcoroutinedispatcher/

@hameno
Copy link

hameno commented Jul 26, 2020

@CDRussell Thanks, actually stumbled upon your blog and implemented that solution 👍

@bungoboingo
Copy link

Wondering if there is any update on this issue? Just curious on timelines, if there are any.

@antonurankar-moloco
Copy link

Hey team. Any news on this?

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

8 participants