Compose: UI testing patterns

Core principle

Test the smallest UI contract that proves the behavior. Prefer plain state-driven UI tests with callbacks. Add integration only when lifecycle, navigation, DI, or platform behavior is the thing under test.

Procedure

1. State the behavior and test concern the task asks you to prove.
2. Inspect the existing test against that concern and choose the smallest sufficient seam from the table below.
3. Keep focused edits within the requested test concern. Do not move test-only helpers into production or broaden production APIs unless that production boundary is itself under test.
4. Drive controlled state or input, synchronize through Compose when needed, and assert an observable semantic, visual, or callback result.
5. Finish with no edit when the existing test already uses the narrowest valid seam and proves the requested behavior.