What problem does it solve?
It solves the coordination problem when Compose UI testing needs to interact with Android View and system-level UI elements using Espresso, such as Dialog windows and soft keyboard behavior.
Core Features & Use Cases
- Compose ↔ Espresso synchronization bridge: Uses the built-in EspressoLink bridge so Compose idling resources are automatically recognized by Espresso without manual IdlingRegistry wiring.
- Correct threading for Espresso calls: Ensures
Espresso.onView(...) runs from the test thread and only after rule.waitForIdle() to prevent deadlocks or main-thread failures.
- Hybrid Activity interaction patterns: Supports one-Activity, two-framework tests where Compose semantics and View hierarchy interactions must both be verified, including optional scoping via
onRootWithViewInteraction for multiple ComposeView hosts.
- Use cases: Dialog focus, IME (soft keyboard) tests, ComposeView embedded in View hierarchies, and focus interactions that cross the Compose/View boundary.
Quick Start
Use an Android Compose test rule with the host Activity, call rule.waitForIdle(), and then interact with Views using Espresso.onView(...) on the test thread for the target window or IME behavior.