Testing with Espresso Interop — One Activity, Two Test Frameworks, One Bridge

The Compose ComposeTestRule and the Espresso onView API operate on the same Activity simultaneously. Compose synchronization (idling resources, frame clock awaits) is bridged into Espresso through a single internal IdlingResource named EspressoLink, so the developer does not register anything manually. The trap is threading: Espresso.onView MUST run on the test thread, not from inside rule.runOnIdle { } or rule.runOnUiThread { }. This skill encodes the canonical interop pattern from androidx.compose.foundation's text-field IME tests.

When to use this skill

• The test must operate on an Android Dialog window (which lives in its own Window and may not be in the Compose semantic tree).
• The test must verify IME (soft keyboard) state — only Espresso's onView(supportsInputMethods()).perform(click()) makes the keyboard appear.
• The screen-under-test is a hybrid Activity with an Android View hierarchy that contains a ComposeView, or vice versa.
• The developer asks "how do I use Espresso and Compose in the same test".
• A test calls Espresso.onView(...) from runOnIdle { } and hangs / throws "cannot be run from the main thread".

When NOT to use this skill

• The test is pure Compose; no Android View interactions exist. Use ../../patterns/structuring-a-compose-test/SKILL.md.
• The synchronization symptom is "test passes locally, flaky on CI" without any View interop. Use ../../synchronization/synchronizing-with-idle/SKILL.md.
• The test is for an androidx.compose.ui.window.Dialog (Compose dialog) — that DOES surface in the semantics tree via isDialog() and does NOT need Espresso. Use ../../finders/composing-semantics-matchers/SKILL.md.

Prerequisites