IssueTracker

Hey thank you for filing this issue. Could you provide a sample code that we can use to verify the described behavior?

Thank you!

Hi, thank you for filing this and proving a sample.

We're updating the way velocity is calculated in the velocity tracker, but the way we add points will remain the same. I agree that the value presented by the onPreFling method seems strange, but you need to take into consideration that it hasn't been consumed by the children of the given NestedScrollConnection. Ideally, you might want to have a look at the onPostFling method where we report the velocity available after the consumption by the children (in you case the LazyColumn is automatically added as part of the nested scroll system, so it will consume part of the velocity). This is because we want to let the LazyColumn consume everything it can before we take the rest of the velocity and use it to change its offset. I took the liberty to update your sample so you can see how that would be achieved. Let me know if that's your intention. Let me know what you find.

    val flingSpec = rememberSplineBasedDecay<Float>()
    val nestedScrollConnection = remember {
        object : NestedScrollConnection {
           
            ...

            override suspend fun onPostFling(consumed: Velocity, available: Velocity): Velocity {
                val initialVelocity = available.y
                return if (abs(initialVelocity) > 1f) {
                    var velocityLeft = initialVelocity
                    var lastValue = 0f
                    AnimationState(
                        initialValue = 0f,
                        initialVelocity = initialVelocity,
                    ).animateDecay(flingSpec) {
                        val delta = value - lastValue
                        val consumed = scrollBy(delta)
                        lastValue = value
                        velocityLeft = this.velocity
                        // It might be necessary to cancel the animation if the fling direction change, this.cancelAnimation()
                    }
                    Velocity(available.x, velocityLeft)
                } else {
                    Velocity(available.x, initialVelocity)
                }

            }
        }
    }

Actually if you use onAllNodes(someMatcher()) you can use fetchSemanticsNodes() which will return a list that can be empty. That is what we mostly recommend for doing these kind of checks. For example, in DemoTest we implemented SemanticsNodeInteractionCollection.isNotEmpty() [1], which is basically the same as isNodePresent().

Andrey is there a clear path forward here we could take or is this worth putting on the back burner?

Update: there are also usecases when users want to know the amount of visible children to assert it with the expected one. The current workaround could be something like:

    rule.onAllNodesWithText("item", substring = true)
        .filter(isPlaced())
        .assertCountEquals(1)
    
    ...
    
    fun isPlaced() = SemanticsMatcher("isPlaced") { node -> node.layoutInfo.isPlaced }

But we need to provide an official api for this use case as well

Can we ask what is the use case for returning these cached nodes?
They do not affect the UI thus it seems we do not need to assert on these cached nodes when testing the UI.

With each Compose update more and more optimizations are being put into these Lazy type views.
Thus it's causing our otherwise accurate UI tests to break more and more.

Our team is confused as to why we have this complicated workaround code for simple assertions.

Our workaround

We overrode every onNode* method we used to filter out these very unexpected nodes.

Extension Methods

// region Cache Patch

/** A patched version of [ComposeTestRule.onNode] that filters out cached views from lazy views. */
fun ComposeTestRule.onNodePatched(matcher: SemanticsMatcher) =
    onNode(matcher and isNotCached())

/** A patched version of [ComposeTestRule.onNodeWithText] that filters out cached views from lazy views. */
fun ComposeTestRule.onNodeWithTextPatched(text: String, substring: Boolean = false, ignoreCase: Boolean = false, useUnmergedTree: Boolean = false) =
    onAllNodesWithText(text = text, substring = substring, ignoreCase = ignoreCase, useUnmergedTree = useUnmergedTree)
        .filterToOneNotCached()

/** A patched version of [ComposeTestRule.onNodeWithTag] that filters out cached views from lazy views. */
fun ComposeTestRule.onNodeWithTagPatched(testTag: String, useUnmergedTree: Boolean = false) =
    onAllNodesWithTag(testTag = testTag, useUnmergedTree = useUnmergedTree)
        .filterToOneNotCached()

/** A patched version of [ComposeTestRule.onNodeWithContentDescription] that filters out cached views from lazy views. */
fun ComposeTestRule.onNodeWithContentDescriptionPatched(label: String) =
    onAllNodesWithContentDescription(label = label)
        .filterToOneNotCached()

/** A patched version of [ComposeTestRule.onAllNodesWithText] that filters out cached views from lazy views. */
fun ComposeTestRule.onAllNodesWithTextPatched(text: String) =
    onAllNodesWithText(text = text)
        .filterOutCached()

/** A patched version of [ComposeTestRule.onAllNodesWithContentDescription] that filters out cached views from lazy views. */
fun ComposeTestRule.onAllNodesWithContentDescriptionPatched(label: String) =
    onAllNodesWithContentDescription(label = label)
        .filterOutCached()

/** Filters out cached views from lazy views and expects 1 or 0 results. */
fun SemanticsNodeInteractionCollection.filterToOneNotCached() =
    filterToOne(isNotCached())

/** Filters out cached views from lazy views and expects 0 or more results. */
fun SemanticsNodeInteractionCollection.filterOutCached() =
    filter(isNotCached())

/**
 * Matches against only nodes that are not "cached" by lazy lists. This allows us to filter out
 * nodes that do not appear in the UI but are reported by Compose's testing framework. These cached
 * nodes cause issues because they will cause assertIsDisplayed to fail due to 2 nodes with the same
 * values are reportedly displayed, but one is displayed and the other is cached. Cached nodes also
 * cause assertDoesNotExist to fail because the cached node that does not exist on the UI does exist
 * according to the test framework.
 *
 * This matcher is used in the methods above to globally filter out these very unexpected nodes.
 * We hope Compose stops reporting these cached nodes in a future update and we can remove this patch.
 *
 * https://issuetracker.google.com/issues/187188981
 */
fun isNotCached() = SemanticsMatcher("isNotCached") { node -> node.layoutInfo.isPlaced }

// endregion

Sorry about that. Agree there are no good reasons to return such cached nodes in most cases. Basically it is only really needed when you test this exact caching logic (some of our lazy layout related tests do that).

I believe they should be filtered out by default with some extra api allowing to get the unfiltered list of nodes. This bug will be dedicated to this work.

At this stage I think we should only be making assertIsDisplayed/assertIsNotDisplayed monotonically more lenient, as they're so widely used that making either of them more strict is likely to break real-world tests and prevent people from upgrading Compose.

The way they are exact inverse of each other means we cannot make one of them more lenient without making the other one more strict. So in WIP patch http://aosp/2703759, to address a different problem, I added an internal strict: Boolean parameter to allow their behavior to start to diverge. I suggest the same approach could be used to make assertIsNotDisplayed more lenient to fix this issue.

Hello team, we've recently encountered this issue while upgrading from Compose 1.4.3 to Compose 1.5.0-beta03. (I couldn't test against the stable version of Compose 1.5 due to AGP and compileSdkVersion requirements, but I haven't found any relevant fixes between the 1.5.0-beta03 and the stable 1.5.0 release.)

For example, the issue manifests in the following ways:

• assertDoesNotExist fails because a cached node still exists.
• assertIsDisplayed fails because the test framework detects more than one displayed node, including cached nodes.
• Tests checking the node count within the tree report inaccurate results due to cached nodes.

Could you please take a look to investigate whether this constitutes a regression? While the workaround with the node placement check (e.g., #comment12) works, this issue leads to numerous test failures with the current lazy list usages. In any case, I would greatly appreciate it if this issue could be prioritized given the impact on testing. Also, I wondered if this could be related to the one reported here: https://issuetracker.google.com/issues/278367269. Thanks for taking a look.

This is a very serious regression that hit me as well when updating to a newer Compose version. IMHO the new optimization is not even dependent on the runtime version of the library, but was somehow introduced in the new Compose Compiler version 1.5.3, which needs to be used when the project's Kotlin version is updated to 1.9.10, because when I downgrade the runtime version of compose to my previous version (BOM 2023.04.01) the error persists.

Please, fix this issue as it's hard to figure out why LazyRow / LazyColumn testing suddenly breaks for no obvious reason.

It does look like it is a regression or at least a significant behavior change introduced in Compose 1.5. Although there was no response/acknowledgment to this FR, I found this issue, which has been closed as Won't Fix.

Thank you very much for providing this fix!

So do I understand that right, to make sure that a node does not exist or is not displayed, we can use assertIsDeactivated()? So assertIsDeactivated() basically means assertDoesNotExistOrIsNotDisplayed()?

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.tv:tv-foundation:1.0.0-alpha11