Compose & Espresso UI Testing Interview Questions
TESTING › UI
Walk me through your strategy for keeping a large instrumented UI test suite reliable in CI, beyond what automatic synchronization gives you for free.
What a strong answer covers: Automatic synchronization only waits for the UI thread and message queue (or the Compose clock) to go idle, so it won't wait for background async work you don't control, meaning you still need IdlingResources or injected fakes with controlled dispatchers for network/database calls. Beyond that, reliability comes from running on consistent emulator images and API levels, disabling animations, isolating test data so tests don't interfere with each other, and treating any flaky test as a bug to fix rather than something to retry away.
When would you reach for Espresso over Compose testing APIs, or vice versa, on a screen that's mid-migration from Views to Compose?
What a strong answer covers: Use createAndroidComposeRule to host the real Activity when the screen mixes both; onView still targets legacy chrome like a Fragment-hosted toolbar or a Dialog outside the Compose subtree, while onNode targets the Compose-rendered content, and both engines can run in the same instrumentation session since Compose testing interoperates with Espresso's idling mechanism. The mistake is assuming you must fully migrate a screen's tests before you can meaningfully test it; you can test the hybrid screen as it actually ships.
A screen shows a spinner, fetches data asynchronously, then renders a list. What's your approach to synchronizing a test with that async work, and what breaks if you get it wrong?
What a strong answer covers: The reliable approach is to inject a fake or test repository with a controllable dispatcher so the fetch completes deterministically before you assert, the same pattern used for ViewModel unit tests; for work you genuinely don't control, register an IdlingResource around the async call, or use composeTestRule.waitUntil to poll for the final state within a timeout as a last resort. Skipping this and relying on default settling gives you intermittent flaky failures, because the test framework only waits for the UI/Compose clock to go idle, not for background work to finish, and can also produce false passes where assertions race the data arriving.