skip to content

A Detox sign-up test's element(by.text('Continue')).tap() fails on iOS with 'Multiple elements found' — what causes it, and what is the robust fix?

level: seniorimportance: should knowfreq 28%

answer

  1. one match or the step fails
  2. previous screen still mounted
  3. unique testID first
  4. withAncestor, and() to scope
  5. atIndex order differs by platform

basics

~20 s

The matcher resolves to several native views, often including a Continue button on a screen still mounted underneath, and Detox fails rather than guess. Give the button a unique testID or scope the match with withAncestor; atIndex is a last resort.

solid answer

~40 s

Detox resolves the matcher in the native hierarchy and acts only when it finds exactly one view; with several and no index it fails — "Multiple elements found" on iOS, an ambiguous-match error on Android. In a sign-up flow the usual cause is a "Continue" button on a previous step that is still mounted under the current screen, or repeated components. The robust fix is a unique `testID` such as `signup.address.continue`. If the component is shared, I scope it: `by.text('Continue').withAncestor(by.id('signup.address'))`, or combine properties with `and()`. `atIndex` works but is fragile: the docs warn indices can differ between iOS and Android and shift as the UI changes.

code

typescript · 9 lines
typescript
import { by, element } from 'detox';

// fails when a previous step's Continue button is still mounted:
// await element(by.text('Continue')).tap();

await element(by.id('signup.address.continue')).tap();

// shared button component, unique container:
await element(by.text('Continue').withAncestor(by.id('signup.payment'))).tap();

go deeper

for a junior

Recall that a Detox matcher must resolve to one element, and that a unique testID is the simplest way to guarantee it.

for a middle

Explain withAncestor, withDescendant, and() and atIndex, and why index order is not portable between platforms.

for a senior

Diagnose hidden mounted screens or duplicated components from the attached hierarchy and fix the matcher at its source.

for a principal

Set conventions for IDs on shared components so ambiguous matches do not recur as the app grows.

## The failure A meal-kit sign-up has a "Continue" button on the email step, the address step and the payment step. A test written as `element(by.text('Continue')).tap()` passes on the first screen and then fails on iOS with **"Multiple elements found for …"**. On Android the equivalent is an ambiguous-match error from Espresso, which Detox wraps with the view hierarchy attached. ## Why Detox refuses to guess When a **Detox** action or expectation runs, the matcher is resolved against the app's native view hierarchy. If it resolves to exactly one view, the action proceeds. If it resolves to several and no index was given, Detox fails the step instead of picking one, because picking silently would make the test pass or fail depending on layout order. Several matches are common in React Native apps: - **Screens that stay mounted.** A navigation stack can keep the previous screen mounted underneath the current one, so its "Continue" button is still in the hierarchy even though the user cannot see it. - **Repeated components.** A list of plan cards each with an "Add" button, or a shared footer rendered twice. - **Repeated copy.** The same string can appear in a step heading, a button and a help line on one screen. - **Broad regexes.** `by.id(/^signup\./)` matches every field on the form. ## Fixes, from most to least robust 1. **A unique `testID`.** `signup.address.continue` on the address step's button removes the ambiguity at the source. This is the answer interviewers want first. 2. **Scope with `withAncestor`.** `element(by.text('Continue').withAncestor(by.id('signup.address')))` matches only the button inside the address step's container. 3. **Combine with `and`.** `element(by.id('primaryButton').and(by.text('Continue')))` when a shared component already carries a generic ID. 4. **`withDescendant`** for the reverse case: the row whose child has a given ID, for example `by.id('plan.card').withDescendant(by.text('Family box'))` — though a key-based row ID such as `plan.card.family` is simpler. 5. **`atIndex(n)` as a last resort.** It picks the n-th match. The Detox docs warn that indices may differ between iOS and Android — on iOS matches are sorted by their x and y positions — and that they shift as the UI changes, which makes index-based tests flaky. | Tool | Scope | Portable across platforms | Survives UI changes | |---|---|---|---| | unique `testID` | exact view | yes | yes | | `withAncestor` / `withDescendant` | relationship | yes | mostly | | `and` | combined properties | yes | mostly | | `atIndex` | position among matches | no guarantee | poorly | ## Counting matches while debugging `getAttributes()` is the one call that tolerates several matches: when the matcher resolves to more than one view, it returns the attributes of all of them under an `elements` array. That makes it a quick diagnostic: ```js const found = await element(by.text('Continue')).getAttributes(); console.log('elements' in found ? found.elements.length : 1); ``` Each entry carries `identifier`, `text`, `visible` and, on iOS, `frame`, which usually shows at a glance that one of the matches sits on a screen the user can no longer see. Remove the diagnostic once the matcher is fixed. ## A diagnostic habit When a matcher is ambiguous or finds nothing, look at the hierarchy Detox attaches to the failure, or inspect the native hierarchy directly (Xcode's view debugger on iOS shows `testID` values as accessibility identifiers). It usually reveals the hidden screen or the duplicated component within seconds. ## Preventing it in a growing app - Give every shared tappable component (`PrimaryButton`, `ListRow`) a `testID` prop and have callers pass a screen-specific value. - Derive row IDs from stable keys (`plan.card.family`), never from positions. - Keep `by.text` for assertions on an element already found by ID, not for lookups. - Review new tests for `atIndex`; each use should carry a reason. ## Rewritten step ```js await element(by.id('signup.address.continue')).tap(); // or, when the button component is shared and only its container is unique: await element(by.text('Continue').withAncestor(by.id('signup.address'))).tap(); ``` A senior answer names the cause (the matcher resolves to several native views, often including a screen still mounted underneath), explains why Detox fails rather than guessing, and prefers unique IDs and scoping over `atIndex`.

  • Why is atIndex(1) a poor fix even when it makes the test pass?
    The index counts matched views in an order Detox derives per platform — on iOS by x and y position — so the same index can point at different buttons on Android. It also shifts whenever a screen adds or reorders matching views, turning a layout tweak into a failing or, worse, wrongly passing test.
  • How would you find which views matched?
    Read the view hierarchy Detox attaches to the failure, or attach Xcode's view debugger to a debug build on the simulator and look for the accessibility identifiers and text. It typically shows a hidden, still-mounted screen or a duplicated component, which tells you whether to add an ID or scope the matcher.

saying these in an interview costs you the question

  • Detox taps the first match when several views match.
  • Only visible views count as matches.
  • atIndex picks the same element on iOS and Android.
  • Adding waitFor fixes a multiple-match error.
  • withAncestor matches views that merely overlap on screen.