Measured: ~half of every authenticated test was fixed setup, dominated by the
UI login (typing email+password, keyboard/SecureField dance, ~8-12s). The test
already creates the account via API and holds its real Kratos session token —
so instead of typing credentials, pass the token as a launch arg and boot the
app already authenticated.
- App (UITestRuntime + iOSApp): reads --ui-test-session-token; after the
--reset-state clear, calls DataManager.setAuthToken(token) and replicates the
post-login init the UI login path runs (getCurrentUser + initializeLookups +
getMyResidences + getTasks) so owner-gated/data-gated screens (residence
detail delete + manage-users, pickers, lists) work on boot. Guarded by
UITestRuntime.isEnabled — no effect on production.
- AuthenticatedUITestCase: in fresh-account mode, create the account + seed its
preconditions BEFORE launch, expose the token via additionalLaunchArguments,
and drop the UI login. Legacy (usesFreshAccount=false) suites still UI-login.
Measured per-test medians: Contractor 34s -> 25s; Task (uses lookups) ~34s ->
16s. TESTING.md updated. All affected suites pass; 0 leaked accounts.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Document the two-target layout, per-test Kratos account isolation, the
seed-before-login precondition rules (requiresResidence /
seedAccountPreconditions), how to run the phased runner, and how to add a suite.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Trey T