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.
We use Google Analytics to see which pages help people. No ads, no profiles. Privacy Policy
Compose, Kotlin, and multiplatform work — the mechanism under the symptom.
229 posts
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.
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.
Listing what I shipped is not the review. Listing what changed for other people is.
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.
Decisions need synchronous time; proposals need written artifacts.
Most of a toolchain is habit rather than measured benefit.
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.
A handover is not a document dump. The test is whether the team ships without you in week one.
Quoting a day rate invites a comparison to salary. Quoting against the outcome changes the question.
Layout Inspector, the compiler reports, Macrobenchmark and the system trace each answer a different question. Using the wrong one produces confident, wrong conclusions, and knowing the split is most of performance work.
Being clearer about the scope does not stop it changing. A written change process does.
Fixed price transfers all estimation risk to you. Price it or change the contract shape.