如何使用TestDispatcher在指定时长后挂起Kotlin无限循环协程？

出现这个问题的核心原因是StandardTestDispatcher的调度规则：只要当前调度队列中存在可立即执行的非挂起任务，调度器就会持续执行这些任务，既不会推进虚拟时间，也不会将执行权交回外层测试协程。
你的循环逻辑是执行doSomething() → delay 5秒 → 再次执行doSomething()，每当虚拟时间推进到下一个5秒节点，循环的下一轮逻辑就会立刻进入待执行队列，调度器会一直优先处理这个不停入队的任务，永远轮不到外层delay(30000)之后的恢复逻辑，表现出来就是流程卡在循环里，哪怕你观测到虚拟时间已经超过30秒也无法退出。

方案1：替换注入的测试调度器为UnconfinedTestDispatcher（改动最小） #

UnconfinedTestDispatcher不会强占调度优先级，协程遇到挂起点时会自动让出执行权，不会一直卡在子协程的无限循环中，业务代码不需要做任何修改，仅调整测试代码中调度器的初始化逻辑即可：

// 替换原有StandardTestDispatcher初始化逻辑
val injectedDispatcher = UnconfinedTestDispatcher(scope.testScheduler)

这个方案适配绝大多数集成测试场景，调度行为和安卓页面生命周期协程的真实运行逻辑更接近，虚拟时间会正常流转，到30秒节点后会自动执行后续断言逻辑。

方案2：手动控制虚拟时间推进（适合精确时序测试） #

如果你需要用StandardTestDispatcher做严格的时序验证，不要直接在外层写delay等待时间，改为手动分段推进虚拟时间，每推进一段就执行完当前时间点的所有待执行任务，避免循环任务占满调度队列：

@Test
fun interval() = scope.runTest {
   val viewModel = get(injectedDispatcher)
   viewModel.onStart()
   // 按5秒间隔分段推进，累计推进30秒
   repeat(6) {
       advanceTimeBy(5000)
       runCurrent() // 执行当前时间点所有排队任务，包括循环中的doSomething
   }
   // 此处虚拟时间恰好为30秒，可直接断言执行结果
   assertSomething(...)
   viewModel.onStop()
}

这个方案时序完全可控，可以精确断言每个时间点的状态、逻辑执行次数，没有调度顺序歧义，适合细粒度的单元测试场景。

方案3：优化业务层循环写法（长期最佳实践） #

协程中不推荐写无状态的while(true)无限循环，要么用协程提供的ticker流实现固定间隔逻辑，要么在循环中加入活跃状态判断，天然兼容所有测试调度器，同时避免协程取消不及时引发的泄漏问题：
如果用ticker流实现：

fun onStart() {
    interval = launch(injectedDispatcher) {
        ticker(5000.milliseconds)
            .flowOn(injectedDispatcher)
            .collect {
                doSomething()
            }
    }
}

如果保留while循环写法，将判断条件从true替换为协程的活跃状态判断：

fun onStart() {
    interval = launch(injectedDispatcher) {
        // 协程被取消时会自动退出循环
        while (isActive) {
            doSomething()
            delay(5000.milliseconds)
        }
    }
}

补充说明：裸写while(true)的循环即使加了delay，在部分调度器实现下依然可能出现不及时让出执行权的问题，while(isActive)是协程中写长循环的标准写法。

内容的提问来源于stack exchange，提问作者Alexey