Skip to content
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

test and testIn do not behave consistently #247

Closed
Antimonit opened this issue Jun 24, 2023 · 1 comment · Fixed by #248
Closed

test and testIn do not behave consistently #247

Antimonit opened this issue Jun 24, 2023 · 1 comment · Fixed by #248

Comments

@Antimonit
Copy link
Contributor

I've noticed that if a Flow is canceled "externally" (e.g. a StateFlow that is canceled only when the CoroutineScope it was launched in is canceled) then test and testIn do not behave the same.

While test reports all unconsumed events and fails the test, testIn does not and passes the test.

private val flow = flow {
  emit(1)
  emit(2)
  awaitCancellation()
}

// Throws
//   app.cash.turbine.TurbineAssertionError: Unconsumed events found:
//    - Item(2)
@Test
fun test() = runTest {
  flow.test {
    assertEquals(1, awaitItem())
  }
}

// Passes
@Test
fun testIn() = runTest {
  turbineScope {
    val turbine = flow.testIn(backgroundScope)
    assertEquals(1, turbine.awaitItem())
  }
}

This is not necessarily caused by the backgroundScope as it can be replicated with a custom CoroutineScope() + scope.cancel() or even when canceling the Job the turbine was launched in.

I've figured out this behavior is caused by not handling CancellationException as a special case. From the docs of CancellationException: "It indicates normal cancellation of a coroutine".

@Antimonit
Copy link
Contributor Author

I've put up a PR that attempts to solve this issue.

I can't say I fully understand the library design and all the consequences this might entail, for example when used with some twisted combination with withTimeout. The library itself does a lot of work to differentiate withTimeout from withTurbineTimeout already and I just don't see that deep.

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

Successfully merging a pull request may close this issue.

1 participant