Locating XCUITest elements without accessibility identifiers

What's really being asked

The interviewer wants to see that you understand the XCUIElement query model and can still automate a screen that was not built with testing in mind, while recognizing that this is a workaround, not a best practice.

The full answer

XCUITest exposes elements through XCUIElementQuery. You can filter by element type such as app.buttons or app.staticTexts, then narrow by visible label like app.buttons["Continue"], by NSPredicate with matching(_:) for partial or case-insensitive matches, or by position using element(boundBy:). Crucially you should scope the query to a parent, for example app.cells.element(boundBy: 0).buttons.firstMatch, so the search is constrained and less ambiguous. You can also use firstMatch to short-circuit the query for performance.

The mistakes people make

Defaulting to absolute indices that break the moment content reorders, or matching on user-facing text that changes under localization or copy edits. Querying the whole app tree repeatedly is also slow because each query resolves the full element snapshot.

What usually comes next

Why are accessibility identifiers preferable? How do identifiers help users with assistive technology as well as tests? How would you persuade the team to add identifiers, and where do you set them in SwiftUI versus UIKit?

A concrete example

A settings row has no identifier. You write let row = app.tables.cells.containing(.staticText, identifier: nil).element(boundBy: 2) which is fragile. A better stopgap is app.cells.staticTexts["Notifications"].firstMatch, but the durable fix is to set accessibilityIdentifier("settings.notifications.row") in code so the test reads app.cells["settings.notifications.row"]. Identifiers are invisible to users, immune to localization, and form a stable contract between code and tests, which is why they beat label and index queries.