# Coroutine Testing - Controlling time

DevFeed: [Coroutine Testing - Controlling time](<https://devfeed.tech/articles/coroutine-testing-controlling-time-25238.md>)

Original publisher: [Read original article](<https://kau.sh/blog/coroutine-testing-time/>)

Author: Kaushik Gopal

Published: 2024-09-04T07:00:00Z

Content type: tutorial

Language: en

Sources: [Kaushik Gopal's Site](<https://devfeed.tech/sources/kaushik-gopal-s-site.md>)

Topics: [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [coroutine](<https://devfeed.tech/tags/coroutine.md>), [coroutine-testing](<https://devfeed.tech/tags/coroutine-testing.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [test](<https://devfeed.tech/tags/test.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [time](<https://devfeed.tech/tags/time.md>)

## AI overview

This tutorial explains virtual time in coroutine tests, focusing on the runCurrent, advanceTimeBy, and advanceUntilIdle APIs. It distinguishes scheduling from execution and demonstrates how StandardTestDispatcher and TestCoroutineScheduler affect test results.

## Source excerpt

series This is part of a series of posts on Coroutine Testing: Picking the right Dispatcher Never ending tests & backgroundscope Controlling time <- Helpful @Junit TestRule extension (coming soon) Full USF example for Android (coming soon) My journey with coroutine testing started with this "simple" requirement -- to control virtual time in concurrent logic. From my previous post: ... If you don't use a StandardTestDispatcher explicitly, then operators like runCurrent, advanceTimeBy etc. have no meaning. I have a confession to make. I was coy saying "have no meaning". I didn't say "won't work" because in reality those apis will "work" just not in the way you'd expect. Let's dive deeper. The 3 apis # There are 3 important apis in coroutine tests to play with time: runCurrent - execute tasks scheduled at the current moment of virtual time advanceTimeBy - advance virtual time by a number of milliseconds and then execute tasks scheduled in the meantime. advanceUntilIdle - similar to advanceTimeBy but instead of advancing by a specific number of milliseconds, it keeps advancing until no more scheduled tasks are found. In the context of coroutine testing, when you think of "time", it refers simply to the order that the TestCoroutineScheduler decides to execute your scheduled coroutines. That's why the definitions above stress on words "execute" vs "scheduled". In reality, these apis belong to the class TestCoroutineScheduler (not StandardTestDispatcher as the coy comment might have indicated). Let's attempt to understand this all, with some code. StandardTestDispatcher & the 3 apis # This animation should illustrate how the different apis are designed to work.1 Your browser doesn't support HTML5 video. Download the video instead. StandardTestDispatcher is good about respecting the 3 apis. A basic test demonstrating the use of runCurrent that shouldn't be surprising: @Test fun test() = runTest(StandardTestDispatcher()) { var result = "X" launch { result = "A" delay(1.seconds)