Asserting Node State and Text — Verify Through the Framework, Not Through fetchSemanticsNode

Once a finder resolves to a SemanticsNodeInteraction, the next step is asserting it. Compose ships a typed assertion for almost every semantic property; the generic assert(matcher) covers the rest. This skill picks the right assertion, distinguishes "exists" from "displayed", and shows when boolean predicates belong inside waitUntil.

When to use this skill

• The developer wants to verify a Switch is on, a Checkbox is unchecked, a Button is enabled, a Text equals an expected string.
• The developer asks about assertIsDisplayed vs assertExists (one verifies on-screen, the other verifies presence in the tree).
• The developer needs a custom assertion via assert(matcher) for a property without a typed extension.
• The developer wants to verify a collection: "exactly 3 items", "at least one is selected", "all are enabled".
• A test compares node.config[...] directly instead of using a typed assertion.

When NOT to use this skill

• The right node cannot be located — see ../../finders/finding-nodes-by-tag-text-content/SKILL.md.
• The assertion is geometric (width, height, position) — see ./asserting-bounds-and-dimensions/SKILL.md.
• The check needs a custom SemanticsMatcher — see ../../finders/composing-semantics-matchers/SKILL.md.
• The state changes asynchronously and the assertion is timing-sensitive — see ../../synchronization/synchronizing-with-idle/SKILL.md.