-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Exceptions being swallowed during tests / UncaughtExceptionsBeforeTest #4141
Comments
There's a potential for the documentation to be improved, but yes, it's not enough to replace the In theory, you can use a |
Would there be a way to detect if a test is not using (Or an existing test needs to be updated, after a change) I don't know if the |
Unfortunately, no: injecting a |
Ah yes, I understand now. I've found that apparently there's a Detekt rule to check if tests which interact with coroutines make use of |
It's safe to assume that, as a general rule of thumb: all of the tests in a test class which replaces the Main scheduler; and injects the TestDispatcher for all of the other dispatchers; should use So even if a test just calls a method which is not launching any coroutine at all, it would be safer to just use |
Yes, if you replace the |
Describe the bug
When replacing the Main Dispatcher with a TestDispatcher, tests are not failing as expected.
I've provided an example below which showcases the issue.
When the Main Dispatcher is replaced, and I don't use
runTest
, as it doesn't seem necessary, exceptions during that test get swallowed, and the test completes successfully.There's some inconsistent behaviour though, and I'm not sure why:
runTest
fails with anUncaughtExceptionsBeforeTest
(4 & 5)I'm not sure if this is intended behaviour.
If it is, I suppose the main issue I have, is that it's not clear that
runTest
should be used for all tests when the Main Dispatcher is replaced with a TestDispatcher;Even if we're not actively interacting with Coroutines.
(no time control / not launching any jobs / not calling suspending functions ...)
One way this can become an issue without it being noticed:
Given a class with corresponding tests which already replaces the Main Scheduler via setup/teardown or a test rule
if a method of this class, which was not launching any coroutine job before, is changed to launch a coroutine,
the existing test(s) won't be using
runTest
.This may result in exceptions being thrown, but the test not failing.
Best case scenario, a later test fails, giving enough information to fix the actual cause.
Worst case scenario, this exception is not thrown anywhere at all, potentially leaving a bug in the code which should have gotten caught by the tests.
Provide a Reproducer
The text was updated successfully, but these errors were encountered: