Skip to content

Feature request: different error messages for hanging test body vs launched coroutines #3069

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
joffrey-bion opened this issue Dec 7, 2021 · 1 comment
Assignees
Labels

Comments

@joffrey-bion
Copy link
Contributor

joffrey-bion commented Dec 7, 2021

From my experience testing a coroutine-based library, with tons of fine-tuned suspension assertions, it has often been important to me to distinguish cases where the test body itself hangs from cases where some coroutines (spawned from deep in the code) are hanging.

When running tests locally it's easy to know by debugging tests and putting a breakpoint at the end of the test method, but when running on CI this is not an option. Sometimes I can't even reproduce test failures locally (because I'm developing on Windows, and the failing test happens in iOS test code on MacOS CI agent).

It would be nice if this error message could make the distinction too:

The test coroutine was not completed after waiting for 5000 ms
kotlinx.coroutines.test.UncompletedCoroutinesError: The test coroutine was not completed after waiting for 5000 ms
	at app//kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt$runTestCoroutine$3$3.invokeSuspend(TestBuilders.kt:231)
	(Coroutine boundary)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTestCoroutine(TestBuilders.kt:257)

Currently I get the same error for both of these test cases:

@Test
fun testTimeoutWithHangingBody() = runTest(dispatchTimeoutMs = 5000) {
    awaitCancellation() // hanging test body
}
    
@Test
fun testTimeoutWithHangingCoroutine() = runTest(dispatchTimeoutMs = 5000) {
    launch {
        awaitCancellation() // hanging launched coroutine
    }
}
@qwwdfsad
Copy link
Collaborator

qwwdfsad commented Dec 7, 2021

Orthogonally to this issue, it can be helpful to run the tests with DebugProbes enabled.
Potentially, we can even integrate with them out-of-the-box and dump all coroutines (or only tests-related) if the probes are enabled

dkhalanskyjb added a commit that referenced this issue Dec 8, 2021
woainikk pushed a commit that referenced this issue Dec 14, 2021
* The error is more verbose: it lists the active children.
* If the test coroutine is already finishing with an error, that error
  is added to the timeout notification as suppressed.
* The timeout is considered more important, so now, if there were
  any uncaught exceptions, they don't take precedence over it but
  are suppressed by it.

Fixes #3066
Fixes #3069
yorickhenning pushed a commit to yorickhenning/kotlinx.coroutines that referenced this issue Jan 28, 2022
* The error is more verbose: it lists the active children.
* If the test coroutine is already finishing with an error, that error
  is added to the timeout notification as suppressed.
* The timeout is considered more important, so now, if there were
  any uncaught exceptions, they don't take precedence over it but
  are suppressed by it.

Fixes Kotlin#3066
Fixes Kotlin#3069
pablobaxter pushed a commit to pablobaxter/kotlinx.coroutines that referenced this issue Sep 14, 2022
* The error is more verbose: it lists the active children.
* If the test coroutine is already finishing with an error, that error
  is added to the timeout notification as suppressed.
* The timeout is considered more important, so now, if there were
  any uncaught exceptions, they don't take precedence over it but
  are suppressed by it.

Fixes Kotlin#3066
Fixes Kotlin#3069
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants