asserting-node-state-and-text

Validate Jetpack Compose semantics node state and text with typed assertions.

303|10|Updated May 15, 2026
One-click install
npx skills add https://github.com/skydoves/android-testing-skills --skill asserting-node-state-and-text
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: asserting-node-state-and-text
Source: https://github.com/skydoves/android-testing-skills/tree/main/compose/assertions/asserting-node-state-and-text
Command: npx skills add https://github.com/skydoves/android-testing-skills --skill asserting-node-state-and-text

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about asserting-node-state-and-text

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does my Jetpack Compose UI test pass when the component is off-screen?

Jetpack Compose UI tests pass off-screen components when using assertExists because it only checks presence in the semantics tree. You must use assertIsDisplayed instead to verify actual user-visible presence on the screen.

How do I check if a Jetpack Compose Switch is toggled or selected in UI tests?

To check if a Jetpack Compose Switch is toggled or selected in UI tests, use the typed SemanticsNodeInteraction assertions assertIsOn and assertIsSelected rather than manually reading semantics configuration properties.

What is the correct way to wait for a Compose element to appear in UI tests?

The correct way to wait for a Compose element to appear is using waitUntil with the boolean isDisplayed() or isNotDisplayed() predicates. This stable polling approach prevents tests from failing fast during asynchronous UI loading.

How do I verify exact text and content descriptions in Jetpack Compose tests?

To verify exact text and content descriptions in Jetpack Compose tests, use the assertTextEquals and assertContentDescriptionEquals assertions. Use assertTextContains for partial checks, which correctly handles merged Text and EditableText semantics.

Can I assert multiple Compose nodes in a collection without manual indexing?

You can assert multiple Compose nodes in a collection without manual indexing by using collection-aware assertions. Apply assertCountEquals to verify cardinality, assertAny to check if a matcher applies, and assertAll to verify every node matches.

Does this Compose UI testing approach support custom semantics matchers?

Yes, this Compose UI testing approach supports custom semantics matchers via an escape hatch. When typed assertions like assertIsDisplayed or assertTextEquals do not cover your specific scenario, you can use the assert(matcher) function for custom validation.