Compose UI tests, sparingly

The tip of the pyramid: a real Compose tree, rendered and clicked

createComposeRule() sets up a Compose UI test — it can host any @Composable content directly, without a full Android activity, which keeps it faster than a true instrumented test on a device. Inside a test, composeTestRule.setContent { … } renders the composable under test.

Nodes are found by what a user would actually see or by a stable tag: onNodeWithText("…") finds a node by its visible text, and onNodeWithTag("…") finds one by an explicit Modifier.testTag("…") for nodes without unique text. Once found, assertIsDisplayed() checks it's actually visible, and performClick() simulates a tap.

For pixel-level regressions — did this screen's layout shift unexpectedly — Roborazzi takes a screenshot during a Robolectric-backed test and diffs it against a saved baseline, giving deterministic pixel comparisons on the JVM instead of a real device.

These are the most expensive tests to write and run, and the ones most likely to be flaky (timing, animation, layout). Keep the count small and pick them for the highest-value flows — booking a walk, not every button on every screen.