Category
Everything we’ve written under Testing.
Part 7 of our XCUITest series, and the start of the performance arc. A practical guide to measuring a UI-test suite before optimising it: which four numbers to collect, how to get a run that can be reported, how to read outcomes from the result bundle, when a before/after comparison is valid, how to confirm which build you measured, and why macOS runs cannot be left unattended. With do's and don'ts for each step.
Part 8 of our XCUITest series. When 84 percent of a test's setUp is launching the app and logging in, launching once per class is the first optimisation to consider. How to implement it in XCTest, how to prove the app is reset between tests, which classes must stay per-method, and how to skip wrong-device tests before the launch happens. Measured at minus 31.9 percent across 23 classes, with do's and don'ts.
Part 9 of our XCUITest series. XCTAssertFalse(x.waitForExistence(timeout: 4)) spends four seconds on every passing run; waitForNonExistence spends one poll. A guide to the waits whose cost does not depend on the app: how to find them in the result bundle, how short each can safely be, how to prove a shortened wait can still fail, and the positive waits that never succeed. With do's and don'ts.
Part 10 of our XCUITest series. Where XCUITest's wait-for-idle time comes from (not activate()), how to disable SwiftUI and UIKit animations from inside the app under a UI-testing launch argument without persisting anything, how to measure the effect with a pre-registered ABA run, and how to split a suite across parallel simulator clones by shared state. Measured at minus 7.70 percent and minus 20.0 percent, with do's and don'ts.
Part 11 of our XCUITest series, closing the performance arc. Three optimisations that look large on paper and measured small: caching provisioning per class (2.1 percent of setUp), keeping the session across relaunches (under 1 percent) and seeding fixtures once per class (inside the noise). How to price a candidate before building it, what actually makes result bundles large, and ten rules for UI-test performance.
Part 1 of our XCUITest series. The five-layer pyramid we test a production SwiftUI app with, why Apple forces the Swift Testing and XCTest split, the millisecond-cheap source-scanning guards, and seven shapes of coverage that cannot fail.
Part 2 of our XCUITest series. One base class, two byte-identical lanes, structural assertions next to AI-vision contracts, a double-gated --uitesting launch argument, and the hidden-button trick that opens any seeded record in a lazy Table.
Part 3 of our XCUITest series. Container ids overwrite their children, the Button authoring form decides what iOS publishes, a macOS Table is an Outline, menus keep their names on title, and a dozen other measured reasons a stamped identifier never reaches the tree.
Part 4 of our XCUITest series. Why a leg's wall-clock is its query count times 19 seconds, why activate() inside a poll costs a minute, why isHittable is not visibility, the tap that landed on another app, and the iPad, iPhone and macOS traps that name the wrong subsystem.
Part 5 of our XCUITest series. A login smoke test that was vacuous for its entire life, Bool helpers that hid a live product defect, skips that report green, a restored session that donates the wrong identity to every later class, and the rules that fix each one.
Part 6 of our XCUITest series. Stale binaries, simulator contention, automation-mode timeouts and dead hosts; the ten-step diagnosis order that stops you blaming the product; the process that keeps a suite honest; and the ten lines to keep if you keep nothing else.