Auditing Compose Test Suite

Auditing a Compose Test Suite — Six-Phase Review, Then Route

This is an index-style skill. It orchestrates the rest of compose-test-skills/ into a fixed-order audit pass over an existing test file or test suite. Each phase produces findings; each finding points at the sibling skill that owns the fix. The audit itself never mutates code — that is the job of the routed skills.

When to use this skill

• The user pastes a *Test.kt (or several) and asks "what's wrong with this", "review this", "audit this".
• The user reports systemic flakes, slow CI, or "the test passes locally but fails on CI".
• The user is preparing a Compose feature for release and wants the test suite vetted.
• The user is migrating from v1 (UnconfinedTestDispatcher) to v2 (StandardTestDispatcher) and wants a checklist of likely-broken tests.
• The user inherited a test file from another team and is unsure what is correct vs accidentally working.

When NOT to use this skill

• The user has a specific failing assertion and wants it fixed — jump directly to the relevant sibling (most often ../../debug/printing-the-semantics-tree/SKILL.md for missed matchers, or ../../synchronization/testing-animations-deterministically/SKILL.md for animation flakes).
• The user is starting a brand-new test from scratch — start with ../../setup/configuring-test-dependencies/SKILL.md, then ../../setup/choosing-test-rule-vs-runtest/SKILL.md, then ../../setup/setting-up-host-vs-device-tests/SKILL.md.
• The user wants performance review of production composables — that is compose-performance-skills, not this repo.

Prerequisites

• Read access to the full test file(s) under review. A single test method is too narrow to audit — patterns emerge across a class.
• The module's build.gradle.kts (for Phase 1 dep checks) and any src/androidTest/AndroidManifest.xml if the test uses a custom Activity.
• Familiarity with the skydoves hot takes encoded in ../docs/SPEC.md §5 (testTag from production, default useUnmergedTree = false, mainClock.autoAdvance = false for animations, waitUntil is wall clock, runOnIdle for state mutations, prefer v2 entry points, Thread.sleep is a smell).

Audit pipeline

Run the six phases in order. Stop and route to the matching sibling skill the moment a phase produces a finding — fixes in earlier phases sometimes invalidate findings in later ones (e.g. switching from v1 to v2 in Phase 1 can change Phase 5 idle behavior).

Phase 1 — Setup correctness

What to check on the build/@Rule/source-set layer:

• Gradle: is androidx.compose.ui:ui-test-manifest on debugImplementation (instrumentation) / testImplementation (host)? Is ui-test-junit4 on the matching configuration as the test class?
• Lint: is TestManifestGradleConfiguration (severity WARNING) being suppressed?
• Rule choice: createComposeRule() vs createAndroidComposeRule<A>() vs createEmptyComposeRule() — does the rule match the host? Is the custom Activity declared in src/androidTest/AndroidManifest.xml?
• v1 vs v2 imports: any androidx.compose.ui.test.junit4.createComposeRule or androidx.compose.ui.test.runComposeUiTest (deprecated WARNING)?
• Mixing surfaces: does the same test class declare both @get:Rule val rule = createComposeRule() AND a runComposeUiTest { } body?
• Source set: is the file in src/test/ (host) or src/androidTest/ (device)? Does its capability set match (no captureToImage, no enableAccessibilityChecks, no ripple-dependent assertions in host)?

Failure modes route to:

• Missing/misconfigured deps, ActivityNotFoundException, lint warning → ../../setup/configuring-test-dependencies/SKILL.md.
• Wrong rule constructor, v1 imports, mixed surfaces, double setContent → ../../setup/choosing-test-rule-vs-runtest/SKILL.md.
• Wrong source set, screenshot test on host, accessibility check on host → ../../setup/setting-up-host-vs-device-tests/SKILL.md.

Phase 2 — Finder discipline

What to check on each onNode* / onAllNodes* call:

• Finder choice: count onNodeWithTag vs onNodeWithText vs onNodeWithContentDescription. Heavy onNodeWithText usage on non-i18n strings is a fragility signal. Skydoves hot take #1: Modifier.testTag("…") belongs in production under a constant; tests find by tag, not text.
• Production tag presence: is the matched tag actually applied with Modifier.testTag(...) in the production composable? If absent, the finder will never match.
• useUnmergedTree: defaults to false. Is the developer flipping it without a stated reason? Is the test relying on a tag inside a merged subtree (e.g. tag on the Text inside a Button) and matching the wrong (parent) node?
• Selector chains: onChild/onParent propagate useUnmergedTree. Any chain that flips the flag mid-traversal is suspicious.
• onAllNodes(...).filter(...) vs custom SemanticsMatcher: is the test re-implementing a prebuilt matcher (hasText, hasClickAction, hasContentDescription)?

Failure modes route to:

• Tag absent in production, text-finder fragility → ../../finders/finding-nodes-by-tag-text-content/SKILL.md.
• Wrong merged/unmerged choice or fragile tree navigation → ../../finders/traversing-the-semantics-tree/SKILL.md.
• Hand-rolled matcher when a prebuilt exists → ../../finders/composing-semantics-matchers/SKILL.md.
• Finder produces zero matches in CI → ../../debug/printing-the-semantics-tree/SKILL.md.

Phase 3 — Assertion strength

What to check on each assert* call:

• assertExists() where the test author meant assertIsDisplayed(): existence in the semantics tree is weaker than on-screen visibility.
• assertCountEquals(n) vs assertAny(matcher): is the test brittle on collection size when it really means "at least one matches"?
• Bounds vs state: assertWidthIsEqualTo / getUnclippedBoundsInRoot are state checks against layout. Mixing them with screenshot assertions duplicates work.
• Text assertions: assertTextEquals("Save") on user-visible strings drifts across i18n; assertTextEquals(context.getString(R.string.save)) is sturdier.
• assertIsOn / assertIsOff / assertIsSelected: these query the toggle/selectable semantics state. Are they being skipped in favor of weaker assertExists?
• Dp.assertIsEqualTo tolerance: defaults to ½ dp. Is the test asserting exact pixel equality where a tolerance is more honest?

Failure modes route to:

• assertExists overuse, brittle count vs intent, toggle/selectable state, text assertions → ../../assertions/asserting-node-state-and-text/SKILL.md.
• Bounds checks → ../../assertions/asserting-bounds-and-dimensions/SKILL.md.

Phase 4 — Action correctness

What to check on each perform* call:

• performGesture { }: @Deprecated everywhere — replace with performTouchInput { }. This is non-negotiable; the SPEC forbids recommending performGesture.
• Coordinate system: performTouchInput { down(Offset(x, y)) } uses node-local coordinates. Tests that compute global coordinates and pass them to a node-relative DSL produce off-screen taps that silently miss.
• Touch DSL extensions: is the test re-implementing click() / longClick() / swipeUp() / pinch(...) from primitive down/moveBy/up calls? Use the high-level extensions when available.
• Text input: performTextInput("foo") appends; performTextReplacement("foo") replaces; performTextClearance() empties. Wrong choice produces "fooSave" instead of "foo".
• IME action: performImeAction() triggers the action set by KeyboardOptions.imeAction. Is the test using Espresso.pressBack() or a key event when performImeAction() is correct?
• Multi-modal: any test mixing performTouchInput and performMouseInput should consider performMultiModalInput { touch { … }; mouse { … } } for a single-pointer-event timeline.
• Scroll: performScrollToNode, performScrollToIndex, performScrollToKey are LazyList-aware — is the test using a brute-force swipeUp instead?

Failure modes route to:

• Deprecated performGesture, coordinate confusion, swipe primitives → ../../actions/injecting-touch-gestures/SKILL.md.
• Text input/replacement/IME action → ../../actions/entering-text/SKILL.md.
• Mouse, key, multi-modal → ../../actions/injecting-mouse-and-keyboard/SKILL.md.
• Scroll containers (performScrollToIndex/Key/Node), performClick → ../../actions/clicking-and-scrolling/SKILL.md.
• Higher-level LazyList patterns (visibility, state.layoutInfo, animated item placement) → ../../patterns/testing-lazy-lists/SKILL.md.

Phase 5 — Time and idle correctness

The flakiest phase. Check each test method end-to-end:

• Thread.sleep(N): forbidden anywhere except screenshot tests waiting on the RenderThread for ripple completion. Skydoves hot take #7. Anywhere else, replace with mainClock.advanceTimeBy(durationMs) (test clock) or rule.waitUntil(timeoutMillis) { … } (wall clock).
• Animation tests: any test that triggers an animation MUST set mainClock.autoAdvance = false before setContent. Otherwise the installed InfiniteAnimationPolicy cancels infinite animations the moment they start with a CancellationException. Skydoves hot take #3.
• Clock vs wall clock: mainClock.advanceTimeUntil { … } uses the test clock; rule.waitUntil(timeoutMillis) { … } uses wall clock. Mixing them in the same test produces flakes — waitUntil will time out while advanceTimeUntil waits for a clock tick that never comes. Skydoves hot take #4.
• State mutations off-thread: any state.value = X from the test thread (not inside runOnIdle/runOnUiThread) races with the recomposer. Skydoves hot take #5.
• v2 queued work: after migrating to androidx.compose.ui.test.v2.*, LaunchedEffects are queued under StandardTestDispatcher. Tests that previously relied on UnconfinedTestDispatcher eager dispatch may need an explicit mainClock.advanceTimeBy(0) or runCurrent() to drain.
• waitUntil timeout: defaults to 1000 ms — is the test using a longer timeout to mask a missing IdlingResource or to hide a wrong-clock issue?

Failure modes route to:

• Thread.sleep, missing IdlingResource, waitUntil confusion, off-thread state mutation, custom IdlingResource for external work → ../../synchronization/synchronizing-with-idle/SKILL.md.
• Frame-rounding, advanceTimeBy granularity, v1/v2 dispatcher migration → ../../synchronization/controlling-the-test-clock/SKILL.md.
• Animation flakes, autoAdvance missing, InfiniteAnimationPolicy CancellationException → ../../synchronization/testing-animations-deterministically/SKILL.md.