Status Update
No update yet.
Comments
kl...@google.com
Hi. Thanks for reporting this. Fixed in alpha-04
ap...@google.com
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug:
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
ap...@google.com
ap...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
ba...@gmail.com
Is there a workaround? Currently we use the following.
val scope = rememberCoroutineScope {
// ui test broke without this.
Dispatchers.Main.immediate
}
Otherwise some navigateToXXX callbacks are invoked on a Room dispatcher. Which breaks the NavGraph.
da...@google.com
My tests are not doing their job of catching bugs due to this issue.
It's pretty bad for the test environment to have different behavior to production. It leads to bugs and makes it so that we can't verify behavior in tests properly.
je...@google.com
lp...@google.com
I ran into this in
We actually have existing tests that should catch this category of issue, essentially the problem looks like:
scope.launch { }
...some other method calls
scope.cancel()
Normally the cancel will happen before the launch, so the block will never start executing, but in tests because it is unconfined this was accidentally passing as the launch always started first. Manually adding a yield() inside the launch makes the test start to fail, although that is still slightly different as normally we wouldn't even get to the point where the launch {} takes effect and invokes the block.
is...@gmail.com
I see this issue has had some recent movement with a pending PR for adding the ability to set the dispatcher responsible for coroutines related to composition to the StandardTestDispatcher. I have ported these changes over to a project I'm working on and have seen a significant increase in the stability of my team's end-to-end tests that leverage the Compose Testing APIs. Previously, we were encountering issues that were only "solved" by passing in Dispatchers.Main in our app code for the majority of our utilizations of rememberCoroutineScope and LaunchedEffect. Are the changes in the PR associated with this issue being prioritized, and when can we expect them to move through?
Description
Currently Compose UI tests use an
LaunchedEffect,rememberComposeScope, and even the coroutine running theRecomposeritself).This is inconsistent with how coroutines are dispatched in non-test environments, where we use the main immediate dispatcher. It is also dangerous because unconfined dispatchers can change the order that code will run in sneaky ways.