Tóth István Zoltán
11/25/2024, 5:19 AMrunTest
?
I understand the reasons behind the delay skipping, but in some cases it is the simple most annoying thing. I've just spent almost 2 hours figuring out why my test fails and found that there is a wait deep-deep in the code which I actually want to happen. You could say that proper organisation of tests solves this and you might be right, but it means spending way more time on test writing than is actually necessary.
For now I simply opted switching to the default dispatcher, which might be a bad idea but at the end it works:
fun autoTest(testFun: suspend AutoTest.() -> Unit) =
runTest {
// Switch to a coroutine context that is NOT a test context. The test context
// skips delays which wreaks havoc with service call timeouts that depend on
// delays actually working.
withContext(Dispatchers.Default) {
ross_a
11/25/2024, 10:51 AMrunBlocking {
withTimeout(..) {
test()
}
}
Dmitry Khalanskiy [JB]
11/25/2024, 11:15 AMIs there any particular reason why we don't have a multi-platform, actually delaying version ofNo reason other than that we didn't have enough manpower to add this functionality yet, and the overwhelming majority of tests are expected to benefit from delay skipping. Given that therunTest
Dispatchers.Default
workaround does exist, fixing this issue is not a top priority.
Why use runTest if you don't want delay skipping, just runBlockingIt's not multiplatform: we don't provide it on JS and Wasm/JS, because it wouldn't work there. For JVM + Native, yes,
runBlocking
is another option. I'd still recommend runTest
for its ability to catch exceptions thrown outside structured concurrency + the timeout functionality.