Kotlin协程单元测试：如何验证Dispatcher的使用

你遇到的核心问题是：StandardTestDispatcher在执行协程任务时，会使用其内部的BlockingEventLoop作为实际的执行调度器，因此在协程上下文中直接获取CoroutineDispatcher时，得到的是这个内部实例而非StandardTestDispatcher本身。直接通过实例对比来验证调度器的方式不可行，需要换用以下几种验证思路：

1. 利用StandardTestDispatcher的可控性验证 #

StandardTestDispatcher是测试专用调度器，支持手动控制任务执行时机。你可以通过控制调度器的执行来确认代码是否在该调度器上被调度：

示例代码 #

@OptIn(ExperimentalCoroutinesApi::class)
class MyClassTest {
    // 假设你的业务类
    class MyClass(private val dispatcher: CoroutineDispatcher) {
        suspend fun test() {
            withContext(dispatcher) {
                Foo.doSomething()
            }
        }
    }

    object Foo {
        var wasCalled = false
        suspend fun doSomething() {
            wasCalled = true
        }
    }

    @Test
    fun testFooExecutedOnTestDispatcher() = runTest {
        val testDispatcher = StandardTestDispatcher(testScheduler)
        val myClass = MyClass(testDispatcher)
        
        // 启动任务但不立即执行
        launch(testDispatcher) { myClass.test() }
        
        // 此时Foo方法未被调用
        assertFalse(Foo.wasCalled)
        
        // 推进调度器执行所有待处理任务
        testScheduler.advanceUntilIdle()
        
        // 验证方法已被执行
        assertTrue(Foo.wasCalled)
    }
}

2. 自定义调度器包装器追踪调用 #

通过包装StandardTestDispatcher，可以直接追踪该调度器是否被用于分发任务：

示例代码 #

@OptIn(ExperimentalCoroutinesApi::class)
class MyClassTest {
    class TrackingDispatcher(private val delegate: CoroutineDispatcher) : CoroutineDispatcher() {
        var dispatchCount = 0
        override fun dispatch(context: CoroutineContext, block: Runnable) {
            dispatchCount++
            delegate.dispatch(context, block)
        }
    }

    @Test
    fun testDispatcherWasUsed() = runTest {
        val testDispatcher = StandardTestDispatcher(testScheduler)
        val trackingDispatcher = TrackingDispatcher(testDispatcher)
        val myClass = MyClass(trackingDispatcher)
        
        myClass.test()
        testScheduler.advanceUntilIdle()
        
        // 验证调度器被使用过
        assertTrue(trackingDispatcher.dispatchCount > 0)
    }
}

3. 给调度器添加自定义上下文元素验证 #

通过给StandardTestDispatcher附加自定义的上下文元素，在业务代码中检查该元素是否存在，从而确认是否在目标调度器上执行：

示例代码 #

@OptIn(ExperimentalCoroutinesApi::class)
class MyClassTest {
    // 定义自定义上下文元素
    private val TestDispatcherKey = object : CoroutineContext.Key<TestMarker> {}
    private class TestMarker : CoroutineContext.Element {
        override val key: CoroutineContext.Key<*> = TestDispatcherKey
    }

    object Foo {
        var executedOnTestDispatcher = false
        suspend fun doSomething() {
            // 检查当前上下文是否包含自定义标记
            executedOnTestDispatcher = coroutineContext[TestDispatcherKey] != null
        }
    }

    @Test
    fun testFooExecutedOnMarkedDispatcher() = runTest {
        val testDispatcher = StandardTestDispatcher(testScheduler) + TestMarker()
        val myClass = MyClass(testDispatcher)
        
        myClass.test()
        testScheduler.advanceUntilIdle()
        
        assertTrue(Foo.executedOnTestDispatcher)
    }
}

关键说明 #

StandardTestDispatcher的设计就是通过内部的BlockingEventLoop来模拟调度行为，所以直接对比CoroutineDispatcher实例是不符合其工作机制的。上述几种方式都是绕过实例对比，从调度行为或自定义标记的角度来验证代码是否在目标调度器上执行。

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