asserting-node-state-and-text

What problem does it solve?

Verifying what a user can actually see and interact with in Jetpack Compose tests becomes unreliable when you use the wrong assertion (for example, confusing presence in the semantics tree with on-screen visibility) or when you manually read semantics configuration.

Core Features & Use Cases

• Correct assertion selection: Use the typed SemanticsNodeInteraction assertions to verify existence, visibility, enabled/disabled state, toggle state, selection, focus, and click actions.
• Accurate user-facing visibility checks: Prefer assertIsDisplayed for “the user sees it” scenarios and assertExists for “it’s present in the tree” scenarios.
• Text and semantic property verification: Validate visible text and content descriptions using assertTextEquals, assertTextContains, and assertContentDescriptionEquals, including handling merged Text and EditableText.
• Collection-aware assertions: Verify cardinality and matcher behavior with assertCountEquals, assertAny, and assertAll instead of indexing into results.
• waitUntil-safe predicates: Use boolean isDisplayed()/isNotDisplayed() inside waitUntil to avoid failing fast during polling.

Example: A flaky UI test that sometimes passes despite the button being off-screen can be fixed by switching from assertExists to assertIsDisplayed and asserting the exact expected label with assertTextEquals.

Quick Start

Use the asserting-node-state-and-text skill to replace any SemanticsNodeInteraction assertExists checks with assertIsDisplayed when the requirement is user-visible, and to map the expected Switch/Button/Text semantics question to the corresponding assertIs*/assertText* call.