延迟对 Kotlin 协程进行单元测试
Unit testing a Kotlin coroutine with delay
我正在尝试对使用 delay() 的 Kotlin 协程进行单元测试。对于单元测试，我不关心 delay()，它只是减慢了测试速度。我想 运行 以某种方式进行测试，在调用 delay() 时实际上不会延迟。
我尝试 运行使用委托给 CommonPool 的自定义上下文连接协程：
class TestUiContext : CoroutineDispatcher(), Delay {
suspend override fun delay(time: Long, unit: TimeUnit) {
// I'd like it to call this
}
override fun scheduleResumeAfterDelay(time: Long, unit: TimeUnit, continuation: CancellableContinuation<Unit>) {
// but instead it calls this
}
override fun dispatch(context: CoroutineContext, block: Runnable) {
CommonPool.dispatch(context, block)
}
}
我希望我可以从上下文的 delay() 方法中 return，但它调用了我的 scheduleResumeAfterDelay() 方法，我不知道如何将它委托给默认调度程序。
如果您不希望有任何延迟，为什么不直接在调度调用中继续继续呢？:
class TestUiContext : CoroutineDispatcher(), Delay {
override fun scheduleResumeAfterDelay(time: Long, unit: TimeUnit, continuation: CancellableContinuation<Unit>) {
continuation.resume(Unit)
}
override fun dispatch(context: CoroutineContext, block: Runnable) {
//CommonPool.dispatch(context, block) // dispatch on CommonPool
block.run() // dispatch on calling thread
}
}
这样 delay() 将立即恢复。请注意，这仍然会延迟挂起，因此其他协程仍然可以 运行 （如 yield()）
@Test
fun `test with delay`() {
runBlocking(TestUiContext()) {
launch { println("launched") }
println("start")
delay(5000)
println("stop")
}
}
立即运行并打印：
start
launched
stop
编辑：
您可以通过自定义 dispatch 函数来控制延续 运行 的位置。
在 kotlinx.coroutines v0.23.0 他们引入了 TestCoroutineContext.
专业版：它可以真正测试 delay 的协程。您可以及时将 CoroutineContext 的虚拟时钟设置为某个时刻并验证预期的行为。
缺点：如果你的协程代码不使用delay，而你只是想让它在调用线程上同步执行，那么它使用起来比来自@的TestUiContext稍微麻烦一些bj0 的回答（你需要在 TestCoroutineContext 上调用 triggerActions() 来让协程执行）。
旁注：
TestCoroutineContext 现在位于从协程版本 1.2.1 开始的 kotlinx-coroutines-test 模块中，并且在该版本以上的版本中将被标记为已弃用或不存在于标准协程库中。
在 kotlinx.coroutines v1.6.0 中更新了 kotlinx-coroutines-test 模块。它允许测试使用 runTest() 方法和 TestScope 来测试挂起代码，自动跳过延迟。
有关如何使用该模块的详细信息，请参阅 documentation。
上一个答案
在 kotlinx.coroutines v1.2.1 中，他们添加了 kotlinx-coroutines-test 模块。它包括 runBlockingTest 协程构建器，以及 TestCoroutineScope 和 TestCoroutineDispatcher。它们允许自动推进时间，以及使用 delay.
显式控制测试协程的时间
使用 TestCoroutineDispatcher、TestCoroutineScope 或 Delay
TestCoroutineDispatcher、TestCoroutineScope 或 Delay 可用于处理在测试的生产代码中制作的 Kotlin 协程中的 delay。
实施
在这种情况下，正在测试 SomeViewModel 的视图状态。在 ERROR 状态下，发出一个视图状态，错误值为 true。在使用 delay 定义的 Snackbar 时间长度过去后，将发出一个新的视图状态，并将错误值设置为 false。
SomeViewModel.kt
private fun loadNetwork() {
repository.getData(...).onEach {
when (it.status) {
LOADING -> ...
SUCCESS ...
ERROR -> {
_viewState.value = FeedViewState.SomeFeedViewState(
isLoading = false,
feed = it.data,
isError = true
)
delay(SNACKBAR_LENGTH)
_viewState.value = FeedViewState.SomeFeedViewState(
isLoading = false,
feed = it.data,
isError = false
)
}
}
}.launchIn(coroutineScope)
}
有很多方法可以处理 delay。 advanceUntilIdle 很好，因为它不需要指定硬编码长度。此外，如果注入 TestCoroutineDispatcher，如 outlined by Craig Russell，这将由 ViewModel 内部使用的同一调度程序处理。
SomeTest.kt
private val testDispatcher = TestCoroutineDispatcher()
private val testScope = TestCoroutineScope(testDispatcher)
// Code that initiates the ViewModel emission of the view state(s) here.
testDispatcher.advanceUntilIdle()
这些也有效：
testScope.advanceUntilIdle()testDispatcher.delay(SNACKBAR_LENGTH)delay(SNACKBAR_LENGTH)testDispatcher.resumeDispatcher()testScope.resumeDispatcher()testDispatcher.advanceTimeBy(SNACKBAR_LENGTH)testScope.advanceTimeBy(SNACKBAR_LENGTH)
没有处理延迟的错误
kotlinx.coroutines.test.UncompletedCoroutinesError: Unfinished coroutines during teardown. Ensure all coroutines are completed or cancelled by your test.
at kotlinx.coroutines.test.TestCoroutineDispatcher.cleanupTestCoroutines(TestCoroutineDispatcher.kt:178)
at app.topcafes.FeedTest.cleanUpTest(FeedTest.kt:127)
at app.topcafes.FeedTest.access$cleanUpTest(FeedTest.kt:28)
at app.topcafes.FeedTest$topCafesTest.invokeSuspend(FeedTest.kt:106)
at app.topcafes.FeedTest$topCafesTest.invoke(FeedTest.kt)
at kotlinx.coroutines.test.TestBuildersKt$runBlockingTest$deferred.invokeSuspend(TestBuilders.kt:50)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)
at kotlinx.coroutines.test.TestCoroutineDispatcher.dispatch(TestCoroutineDispatcher.kt:50)
at kotlinx.coroutines.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuation.kt:288)
at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(Cancellable.kt:26)
at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.kt:109)
at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:158)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.async(Builders.common.kt:91)
at kotlinx.coroutines.BuildersKt.async(Unknown Source)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.async$default(Builders.common.kt:84)
at kotlinx.coroutines.BuildersKt.async$default(Unknown Source)
at kotlinx.coroutines.test.TestBuildersKt.runBlockingTest(TestBuilders.kt:49)
at kotlinx.coroutines.test.TestBuildersKt.runBlockingTest(TestBuilders.kt:80)
at app.topcafes.FeedTest.topCafesTest(FeedTest.kt:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access[=24=]0(ParentRunner.java:58)
at org.junit.runners.ParentRunner.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
我正在尝试对使用 delay() 的 Kotlin 协程进行单元测试。对于单元测试，我不关心 delay()，它只是减慢了测试速度。我想 运行 以某种方式进行测试，在调用 delay() 时实际上不会延迟。
我尝试 运行使用委托给 CommonPool 的自定义上下文连接协程：
class TestUiContext : CoroutineDispatcher(), Delay {
suspend override fun delay(time: Long, unit: TimeUnit) {
// I'd like it to call this
}
override fun scheduleResumeAfterDelay(time: Long, unit: TimeUnit, continuation: CancellableContinuation<Unit>) {
// but instead it calls this
}
override fun dispatch(context: CoroutineContext, block: Runnable) {
CommonPool.dispatch(context, block)
}
}
我希望我可以从上下文的 delay() 方法中 return，但它调用了我的 scheduleResumeAfterDelay() 方法，我不知道如何将它委托给默认调度程序。
如果您不希望有任何延迟，为什么不直接在调度调用中继续继续呢？:
class TestUiContext : CoroutineDispatcher(), Delay {
override fun scheduleResumeAfterDelay(time: Long, unit: TimeUnit, continuation: CancellableContinuation<Unit>) {
continuation.resume(Unit)
}
override fun dispatch(context: CoroutineContext, block: Runnable) {
//CommonPool.dispatch(context, block) // dispatch on CommonPool
block.run() // dispatch on calling thread
}
}
这样 delay() 将立即恢复。请注意，这仍然会延迟挂起，因此其他协程仍然可以 运行 （如 yield()）
@Test
fun `test with delay`() {
runBlocking(TestUiContext()) {
launch { println("launched") }
println("start")
delay(5000)
println("stop")
}
}
立即运行并打印：
start
launched
stop
编辑：
您可以通过自定义 dispatch 函数来控制延续 运行 的位置。
在 kotlinx.coroutines v0.23.0 他们引入了 TestCoroutineContext.
专业版：它可以真正测试 delay 的协程。您可以及时将 CoroutineContext 的虚拟时钟设置为某个时刻并验证预期的行为。
缺点：如果你的协程代码不使用delay，而你只是想让它在调用线程上同步执行，那么它使用起来比来自@的TestUiContext稍微麻烦一些bj0 的回答（你需要在 TestCoroutineContext 上调用 triggerActions() 来让协程执行）。
旁注：
TestCoroutineContext 现在位于从协程版本 1.2.1 开始的 kotlinx-coroutines-test 模块中，并且在该版本以上的版本中将被标记为已弃用或不存在于标准协程库中。
在 kotlinx.coroutines v1.6.0 中更新了 kotlinx-coroutines-test 模块。它允许测试使用 runTest() 方法和 TestScope 来测试挂起代码，自动跳过延迟。
有关如何使用该模块的详细信息，请参阅 documentation。
上一个答案
在 kotlinx.coroutines v1.2.1 中，他们添加了 kotlinx-coroutines-test 模块。它包括 runBlockingTest 协程构建器，以及 TestCoroutineScope 和 TestCoroutineDispatcher。它们允许自动推进时间，以及使用 delay.
使用 TestCoroutineDispatcher、TestCoroutineScope 或 Delay
TestCoroutineDispatcher、TestCoroutineScope 或 Delay 可用于处理在测试的生产代码中制作的 Kotlin 协程中的 delay。
实施
在这种情况下，正在测试 SomeViewModel 的视图状态。在 ERROR 状态下，发出一个视图状态，错误值为 true。在使用 delay 定义的 Snackbar 时间长度过去后，将发出一个新的视图状态，并将错误值设置为 false。
SomeViewModel.kt
private fun loadNetwork() {
repository.getData(...).onEach {
when (it.status) {
LOADING -> ...
SUCCESS ...
ERROR -> {
_viewState.value = FeedViewState.SomeFeedViewState(
isLoading = false,
feed = it.data,
isError = true
)
delay(SNACKBAR_LENGTH)
_viewState.value = FeedViewState.SomeFeedViewState(
isLoading = false,
feed = it.data,
isError = false
)
}
}
}.launchIn(coroutineScope)
}
有很多方法可以处理 delay。 advanceUntilIdle 很好，因为它不需要指定硬编码长度。此外，如果注入 TestCoroutineDispatcher，如 outlined by Craig Russell，这将由 ViewModel 内部使用的同一调度程序处理。
SomeTest.kt
private val testDispatcher = TestCoroutineDispatcher()
private val testScope = TestCoroutineScope(testDispatcher)
// Code that initiates the ViewModel emission of the view state(s) here.
testDispatcher.advanceUntilIdle()
这些也有效：
testScope.advanceUntilIdle()testDispatcher.delay(SNACKBAR_LENGTH)delay(SNACKBAR_LENGTH)testDispatcher.resumeDispatcher()testScope.resumeDispatcher()testDispatcher.advanceTimeBy(SNACKBAR_LENGTH)testScope.advanceTimeBy(SNACKBAR_LENGTH)
没有处理延迟的错误
kotlinx.coroutines.test.UncompletedCoroutinesError: Unfinished coroutines during teardown. Ensure all coroutines are completed or cancelled by your test.
at kotlinx.coroutines.test.TestCoroutineDispatcher.cleanupTestCoroutines(TestCoroutineDispatcher.kt:178) at app.topcafes.FeedTest.cleanUpTest(FeedTest.kt:127) at app.topcafes.FeedTest.access$cleanUpTest(FeedTest.kt:28) at app.topcafes.FeedTest$topCafesTest.invokeSuspend(FeedTest.kt:106) at app.topcafes.FeedTest$topCafesTest.invoke(FeedTest.kt) at kotlinx.coroutines.test.TestBuildersKt$runBlockingTest$deferred.invokeSuspend(TestBuilders.kt:50) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56) at kotlinx.coroutines.test.TestCoroutineDispatcher.dispatch(TestCoroutineDispatcher.kt:50) at kotlinx.coroutines.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuation.kt:288) at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(Cancellable.kt:26) at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.kt:109) at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:158) at kotlinx.coroutines.BuildersKt__Builders_commonKt.async(Builders.common.kt:91) at kotlinx.coroutines.BuildersKt.async(Unknown Source) at kotlinx.coroutines.BuildersKt__Builders_commonKt.async$default(Builders.common.kt:84) at kotlinx.coroutines.BuildersKt.async$default(Unknown Source) at kotlinx.coroutines.test.TestBuildersKt.runBlockingTest(TestBuilders.kt:49) at kotlinx.coroutines.test.TestBuildersKt.runBlockingTest(TestBuilders.kt:80) at app.topcafes.FeedTest.topCafesTest(FeedTest.kt:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner.run(ParentRunner.java:290) at org.junit.runners.ParentRunner.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access[=24=]0(ParentRunner.java:58) at org.junit.runners.ParentRunner.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33) at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230) at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)