عمليات التحقق وتنفيذ الإجراءات

Finding a node is only half the job. To prove your UI behaves, you add an assertion that states what should be true about that node. ✅

The most common assertion is assertIsDisplayed. It confirms the node is actually visible to the user, not just present in the tree.

Watch the difference: assertExists checks the node is in the tree, while assertIsDisplayed also checks it is on screen and not clipped away.

You can chain several checks on one node. Each returns the node again, so the test reads like a clear sentence about your UI state.

To simulate a tap, call performClick on a found node. Compose dispatches the same click your real users would trigger.

For input fields, performTextInput types characters into the focused field, letting you test forms exactly as a user would fill them.

The classic flow is act then assert: perform a click, then verify the new state appeared. This mirrors how a person uses your app.

Beyond visibility, you can check toggles. assertIsOn and assertIsOff verify switches and checkboxes hold the value you expect.

You want to confirm a button is genuinely on screen, not merely present in the tree. Which assertion do you use?

When you grab a group with onAllNodes, verify how many matched using assertCountEquals. It is perfect for checking list sizes.

Replacing text? Call performTextClearance first, then performTextInput, so old characters do not stick around and break your check.

Good assertions describe behavior, not pixels. Aim for tests that read like requirements, so a failure instantly tells you what behavior broke.

You drive the UI with actions like performClick and performTextInput, then prove the result with assertions like assertIsDisplayed. That is the heart of UI testing. 🎯