Dmitry Khalanskiy [JB]10/18/2023, 2:52 PM
, it is recommended to avoid
, and especially `advanceTimeBy`: https://github.com/Kotlin/kotlinx.coroutines/issues/3919 Already, many tests can be written more idiomatically without them, though clearly far from all. The issue describes the plan to increase the number of tests that don't need these functions. A request to you: the next time you reach for one of these functions, please check the "Alternatives to each manual execution control function" section of the issue to see if the proposed replacements would suit your needs; if not, leave a comment; if yes, leave a thumbs-up under one of the comments.
Pablichjenkov10/18/2023, 3:12 PM
. I will check the thread later.
Joffrey10/18/2023, 3:13 PM
is, all the "real-time" stuff is already done (we already waited for the real-life second with
___ A ___
), so it doesn't show the problem you're trying to discuss there I believe. Maybe you meant to suggest a scenario where
is not called, and instead we have
Dmitry Khalanskiy [JB]10/18/2023, 3:17 PM
Joffrey10/18/2023, 3:18 PM
and wait for actual time when actual time is necessary (e.g. if there are tasks that run under
Dmitry Khalanskiy [JB]10/18/2023, 3:36 PM
Joffrey10/18/2023, 3:38 PM
equivalents for the ones that cannot be covered by
(if such things are in fact needed). Correct?
Dmitry Khalanskiy [JB]10/18/2023, 3:44 PM
, but there's a suspicion that they don't properly work even for them: namely,
is used to wait for spawned coroutines to finish (but doesn't do quite that), and
is used to wait for all initialization to complete (but a
function could suit the use case better). See the "Alternatives to each manual execution control function" section.
Joffrey10/18/2023, 3:45 PM
Dmitry Khalanskiy [JB]10/18/2023, 4:09 PM
You mean it doesn't wait for coroutines that are outside the test scheduler, right?No, we can't do anything about this. The test framework needs to learn about the coroutines somehow.
Or do you mean it doesn't wait for the coroutines to finish, but only to reach a suspension point that doesn't resume unless something else happens?Where this "something else" is outside the control of the test scheduler, yes. I think it's exactly the reason why people find
confusing sometimes: structured concurrency urges us to think in terms of tasks (each represented as a coroutine), but
breaks this abstraction a little, forgetting about tasks (and the test framework's involvement) in the middle of their execution.