Diagnosing and stabilizing flaky XCUITests

WHAT THIS TESTS The interviewer is probing senior judgment: do you treat flakiness as a quality defect to be diagnosed, or do you paper over it with retries and sleeps that erode trust in the suite.

A GOOD ANSWER COVERS Name the usual causes. Timing races where the assertion runs before the view appears; fix by waiting on element.waitForExistence(timeout:) or XCTNSPredicateExpectation rather than sleeping. Animations that change hit-testing mid-tap; disable them via launch environment. Real network dependence with variable latency and failures; stub responses so tests are hermetic. Shared or leftover state such as cached login, onboarding flags, or keychain data; reset by passing launch arguments that put the app in a known state. Volatile element ordering; query by stable identifiers. Device or simulator pressure on CI causing slow rendering; allocate generous but bounded timeouts.

COMMON WRONG ANSWERS Sprinkling Thread.sleep or sleep() to mask races, which slows the suite and only reduces flakiness probabilistically. Configuring CI to retry failed tests until they pass, which hides genuine regressions. Blaming the simulator without evidence.

LIKELY FOLLOW-UPS How do you reproduce a flaky failure locally? What is the value of the test attachments and screenshots in the result bundle? How would you quarantine a flaky test without deleting coverage, and how do you track it to resolution?

ONE CONCRETE EXAMPLE A test taps a Submit button that appears after a spinner. Intermittently it fails because the tap fires while the spinner is still shown. The systematic fix replaces a guessed sleep with XCTAssertTrue(app.buttons["submit"].waitForExistence(timeout: 5)) before tapping, stubs the backing request to return instantly, and disables animations through the launch environment. The test then passes deterministically on every CI run, and the result bundle screenshots confirm the corrected timing.