createComposeRule y finders

Manual testing is slow and easy to forget. A UI test launches your Composable and checks it automatically, catching breakages before your users ever do. 🧪

Every Compose test starts with a test rule. It hosts your Composables in a controlled environment so you can render, inspect, and interact with them from test code.

For pure UI with no Activity, createComposeRule gives you a lightweight rule. You attach it as a JUnit @get:Rule field in your test class.

Use setContent on the rule to render the Composable you want to verify. This is your test's UI, just like in a real Activity.

Once your UI is on screen, you need a finder to grab a specific element. Finders search the semantics tree and return a node you can assert on.

The friendliest finder is onNodeWithText. Give it the text shown on screen and it returns that exact node for you to check.

For images and icons with no visible text, use onNodeWithContentDescription. It matches the accessibility label, which keeps tests and screen readers in sync.

onNode finds a single match and fails if there are several. When you expect a group of elements, reach for onAllNodes to get a collection instead.

You want to locate an icon button that has no visible text. Which finder fits best?

A finder does not search immediately. It captures your intent, and the actual lookup happens when you call an assertion or action on it.

When a finder matches nothing, the test fails with a clear message and even prints the current node tree. That makes debugging a missing element fast.

Need a real Activity, resources, or navigation? Swap in createAndroidComposeRule, which launches an Activity and still exposes the same finder API.

You set up a compose rule, render with setContent, then locate elements with finders like onNodeWithText. That foundation powers every Compose test you write. 🎉