Compose & Espresso UI Testing Flashcards
TESTING › UI
- What is the difference between createComposeRule() and createAndroidComposeRule()?
- createComposeRule() hosts Compose content without a specific Activity, while createAndroidComposeRule<T>() launches activity T so you can also access the Activity instance. Both let you call setContent {} and query the semantics tree.
- What does Compose UI testing actually interact with instead of the real view hierarchy?
- The semantics tree, a parallel structure describing UI meaning for accessibility and testing. Finders, assertions, and actions all operate on semantics nodes, not raw Composables or pixels.
- How do you give a Composable a stable identifier for testing, and how do you find it?
- Attach Modifier.testTag("tag") to the Composable, then locate it with composeTestRule.onNodeWithTag("tag"). Tags are useful when there is no visible text or content description to match on.
- Name the three categories of Compose test operations and give an example of each.
- Finders (onNodeWithText, onNodeWithTag), actions (performClick, performTextInput, performScrollTo), and assertions (assertIsDisplayed, assertExists, assertTextEquals). You chain them: onNode...().performClick().
- What is the difference between assertExists() and assertIsDisplayed()?
- assertExists() only checks the node is present in the semantics tree; assertIsDisplayed() additionally requires it to be visible on screen (within bounds, not clipped/hidden). A node can exist without being displayed.
- When do you need useUnmergedTree = true in a Compose finder?
- By default Compose merges descendant semantics into a parent (e.g. a Button merges its child Text). useUnmergedTree = true queries the unmerged tree so you can match an individual child node that the merge would otherwise hide.
- What is Espresso's core onView pattern?
- onView(viewMatcher).perform(viewAction).check(viewAssertion). For example onView(withId(R.id.btn)).perform(click()).check(matches(isDisplayed())). ViewMatchers locate, ViewActions interact, ViewAssertions verify.
- How do you test items in a ListView, GridView, or Spinner with Espresso?
- Use Espresso.onData() with a matcher on the backing data, not onView(). onData scrolls AdapterView-backed widgets to the matching item, which onView cannot reliably reach because off-screen items are not in the hierarchy.
- How do Espresso and Compose handle asynchronous work, and when do you need an IdlingResource?
- Both auto-synchronize: they wait for the message queue and UI to be idle before each action/assertion. For background work invisible to the framework (threads, network), register a custom IdlingResource (e.g. CountingIdlingResource) so the test waits for it.