You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add extension functions for modifying multiple DelayController at once.
Use case: This is useful for advanced testing situations where the interaction of multiple controllers is being tested.
In addition, a lot of early users of the library have shared that they are making multiple TestCoroutineDispatcher instances in a test (i.e. IO, Default, and Main). While the recommended style is to use one TestCoroutineDispatcher unless explicitly testing dispatcher interactions, the ergonomics will be better when tests are written in this style with aggregate extensions.
Depends on idle implementation in #1202 to allow advanceUntilIdle to be implemented.
The text was updated successfully, but these errors were encountered:
Agreed - I'm not actually sure this one needs to be part of the library since the use case for advancing time in multiple TCD is unclear.
One option is to ensure the idle implementation in #1202 also allows for a developer to create their own versions. Right now it's not possible to create "correct" aggregate advanceTime* implementations using the interface of DelayController since there is no way to figure out which dispatcher has the "shortest pending delay."
I'd like to leave this ticket open until 1202 is resolved and see if anyone has a more concrete use case.
Add extension functions for modifying multiple DelayController at once.
Use case: This is useful for advanced testing situations where the interaction of multiple controllers is being tested.
In addition, a lot of early users of the library have shared that they are making multiple TestCoroutineDispatcher instances in a test (i.e. IO, Default, and Main). While the recommended style is to use one TestCoroutineDispatcher unless explicitly testing dispatcher interactions, the ergonomics will be better when tests are written in this style with aggregate extensions.
Depends on idle implementation in #1202 to allow advanceUntilIdle to be implemented.
The text was updated successfully, but these errors were encountered: