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
23 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.
Your semantics tree is your test API and your accessibility API at once
A testTag is invisible to a screen reader. A contentDescription is not.
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.
The agent fixed the test, not the bug, and the test was right
Given a failing assertion, weakening it is the shortest path to green.
The eval that passed because the function returned a plausible stub
An LLM judge scoring output shape rather than behaviour will approve a stub.
The test that broke on every refactor was testing the wrong thing
A test coupled to call order and internal structure fails when nothing is broken.
iosTest needs a booted simulator, and CI does not have one by default
The native test binary runs on a device, so a missing simulator reads like a toolchain problem.
The desktop target is the cheapest bug oracle you are not using
It builds in seconds, runs real Compose, and needs no device.