What a Compose test suite should actually contain
A useful Compose suite is mostly unit tests, a layer of state-driven component tests, screenshot tests for visual regressions, and a handful of journeys. The shape matters more than the count.
testing
7 posts
A flaky test is a timing assumption you didn't know you made
Compose's test framework auto-syncs with the composition, so most tests need no waiting at all. The failures come from things that never go idle, and from work the framework cannot see.
Find, act, assert — and the rule that decides which test to write at all
Compose testing is finders, actions and assertions over the semantics tree. The API is small; the judgment is choosing between a unit test, a Compose test with a fake, and a full instrumented test.
Your UI tests query the accessibility tree, which is why testTag is a last resort
Compose UI tests match against the semantics tree, not the layout. Selecting by text and content description tests what users perceive; selecting by testTag tests an implementation detail you invented for the test.
Automated checks find the missing labels. They can't tell you the label is wrong.
Compose's accessibility checks catch touch targets, contrast and missing labels automatically. The failures they cannot detect — wrong labels, bad order, gesture-only actions — need a person, and knowing the split makes both cheaper.
Take the clock away and animations become testable
Compose tests idle-wait by default, which makes animated UI either flaky or untested. Disabling autoAdvance gives you frame-level control, turning 'wait and hope' into deterministic assertions at chosen moments.
adb install -r doesn't kill your app, so your screenshot is a lie
Reinstalling over a running app leaves the old process alive. Every 'fixed it, look' screenshot taken without a force-stop is unfalsifiable.