Testing With Espresso Interop

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

• androidx.test.espresso:espresso-core on androidTestImplementation.
• androidx.compose.ui:ui-test-junit4 on androidTestImplementation and androidx.compose.ui:ui-test-manifest on debugImplementation (see ../../setup/configuring-test-dependencies/SKILL.md).
• An Activity that hosts both layers — FragmentActivity is the standard pick; a custom Activity declared in src/androidTest/AndroidManifest.xml also works.
• The test class skeleton from ../../patterns/structuring-a-compose-test/SKILL.md.

Workflow

• 1. Use createAndroidComposeRule<A>() (v2) for the host Activity. Cited from compose/foundation/foundation/src/androidDeviceTest/kotlin/androidx/compose/foundation/textfield/TextFieldFocusCustomDialogTest.kt:60:

import androidx.compose.ui.test.junit4.v2.createAndroidComposeRule
import androidx.fragment.app.FragmentActivity
import kotlinx.coroutines.test.StandardTestDispatcher

@get:Rule
val rule = createAndroidComposeRule<FragmentActivity>(StandardTestDispatcher())

• 2. Set Compose content with rule.setContent { }, then call rule.waitForIdle(). This drains the Compose recomposer/effect queue so the next Espresso interaction sees a stable view tree.

• 3. Drive the View layer from the test thread via Espresso.onView(...). Do NOT wrap this call in runOnIdle or runOnUiThread.

import androidx.test.espresso.Espresso
import androidx.test.espresso.action.ViewActions
import androidx.test.espresso.matcher.ViewMatchers

rule.waitForIdle()
Espresso.onView(ViewMatchers.supportsInputMethods()).perform(ViewActions.click())

Cited from TextFieldFocusCustomDialogTest.kt:117-119. The full IME test:

@Test
fun keyboardShown_forFieldInAndroidDialog_…() {
    val focusRequester = FocusRequester()
    val keyboardHelper = KeyboardHelper(rule)

    rule.setContent {
        wrapContent {
            keyboardHelper.initialize()
            LaunchedEffect(Unit) { focusRequester.requestFocus() }
            BasicTextField(
                value = "",
                onValueChange = {},
                modifier = Modifier.focusRequester(focusRequester),
            )
        }
    }

    rule.waitForIdle()
    // The dialog's window must be focused for the IME to actually show.
    Espresso.onView(ViewMatchers.supportsInputMethods()).perform(ViewActions.click())

    keyboardHelper.waitForKeyboardVisibility(visible = true)
}

• 4. Mix Compose and Espresso assertions freely on the test thread. The two APIs run against the same Activity.

rule.onNodeWithTag("submit").performClick()
Espresso.onView(ViewMatchers.withId(R.id.legacy_toast)).check(matches(ViewMatchers.isDisplayed()))

• 5. (Optional) Scope Compose finders to a sub-tree resolved by Espresso. When the Activity contains multiple Compose hosts and a single Espresso ViewInteraction identifies which one to interact with, use onRootWithViewInteraction(viewInteraction). This is supported only on AndroidComposeTestRule; non-Android test rules throw "This implementation of ComposeTestRule does not support onRootWithViewInteraction.".

val nestedComposeView = Espresso.onView(ViewMatchers.withId(R.id.nested_compose))
rule.onRootWithViewInteraction(nestedComposeView).onNodeWithTag("submit").performClick()

• 6. Trust the EspressoLink bridge. Compose's IdlingResources — recomposer, snapshot, frame clock — are aggregated by ComposeIdlingResource and surfaced to Espresso through a single IdlingResource named "Compose-Espresso link". Cited from compose/ui/ui-test/src/androidMain/kotlin/androidx/compose/ui/test/EspressoLink.android.kt:34-84. The framework registers and unregisters it inside withStrategy { } (lines 58-73). The developer does NOT need IdlingRegistry.getInstance().register(...) for Compose state.

• 7. Conversely, Espresso idling resources are visible to Compose. Anything registered via IdlingRegistry.getInstance().register(…) is awaited by rule.waitForIdle() because the rule polls Espresso through the same bridge.