Kotlin协程库中sample操作符导致测试挂起问题解析

问题现象

在使用Kotlin协程库进行Android开发时，开发者在测试ViewModel时遇到了一个奇怪的现象：当对MutableSharedFlow应用sample操作符后，使用runTest进行的单元测试会无限挂起；而移除sample操作符后，测试则能正常完成。

问题本质

这个问题的根源在于测试代码违反了结构化并发的原则。在测试中，开发者手动创建了一个CoroutineScope并传递了测试调度器，这种做法会导致协程泄漏而无法正常完成。特别是当使用sample这类具有时间窗口的操作符时，问题会更加明显。

技术细节

错误示例分析

以下是一个典型的错误测试写法：

@Test
fun repro() = runTest {
  val dispatcher = coroutineContext[CoroutineDispatcher]!!
  val flow = MutableSharedFlow<Int>()
  val scope = CoroutineScope(dispatcher)
  scope.launch {
    flow.sample(300L).collect {}
  }
}

这种写法存在两个主要问题：

1. 手动创建CoroutineScope破坏了结构化并发
2. 没有正确处理协程的生命周期管理

正确测试方法

正确的测试应该使用backgroundScope来管理协程：

@Test
fun correctTest() = runTest {
  val flow = MutableSharedFlow<Int>()
  backgroundScope.launch {
    flow.sample(300L).collect {}
  }
}

Android ViewModel测试最佳实践

在Android ViewModel测试中，推荐的做法是注入协程作用域：

1. 生产代码中使用viewModelScope
2. 测试代码中注入backgroundScope

这样可以确保：

• 生产环境使用正确的生命周期管理
• 测试环境能够正确控制协程的执行和取消

为什么sample操作符会导致挂起

在测试环境中，当使用sample操作符时：

1. 测试调度器知道需要定期检查新元素（每300ms）
2. 测试会持续等待这些定期检查
3. 导致测试无法正常结束

而没有sample操作符时：

1. 虽然协程仍然泄漏
2. 但测试调度器认为没有更多工作需要执行
3. 因此测试会"错误地"完成

解决方案总结

1. 始终遵循结构化并发原则
2. 在测试中使用backgroundScope而非手动创建作用域
3. 对于ViewModel测试，考虑注入协程作用域
4. 避免直接操作调度器，使用测试库提供的工具

通过遵循这些原则，可以避免测试挂起问题，同时编写出更健壮、更可靠的协程代码。