5895b387be
Replace ZStack-with-gradient patterns with idiomatic .background() modifier across onboarding, customize, and settings views. Add accessibility identifiers to Year View charts for UI test automation. Mark 67 impossible-to-automate tests RED in QA plan and scaffold initial Year View and Settings onboarding tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.4 KiB
3.4 KiB
UI Test Prompt Template (QA Plan Driven)
Copy/paste this into Claude (or Codex), then replace placeholders.
Task:
Create 3 solid iOS UI tests from the QA plan that compile and run reliably using the existing test architecture.
Project:
- Root: /Users/treyt/Desktop/code/Feels
- QA source: /Users/treyt/Desktop/code/Feels/docs/Feels_QA_Test_Plan.xlsx
Optional explicit test IDs/names from me (if provided, prioritize these):
<PASTE_TEST_IDS_AND_NAMES_HERE_OR_LEAVE_EMPTY>
Mandatory references (read before coding):
- /Users/treyt/Desktop/code/Feels/docs/XCUITest-Authoring.md
- /Users/treyt/Desktop/code/Feels/AGENTS.md
- /Users/treyt/Desktop/code/Feels/Tests iOS/README.md
- /Users/treyt/Desktop/code/Feels/Tests iOS/Helpers/BaseUITestCase.swift
- /Users/treyt/Desktop/code/Feels/Tests iOS/Helpers/WaitHelpers.swift
- /Users/treyt/Desktop/code/Feels/Shared/AccessibilityIdentifiers.swift
- Existing suites in /Users/treyt/Desktop/code/Feels/Tests iOS/ (use them for style/patterns)
Selection rules:
1. If I pasted specific QA IDs/names, use those first.
2. If fewer than 3 are provided, choose remaining from the spreadsheet.
3. Pick the easiest automatable tests (low setup complexity, deterministic UI state, no external dependencies).
4. Skip cases likely to be flaky or blocked (network dependency, unstable animation-only behavior, uncertain app hooks).
5. Briefly justify why each selected test is “easy + stable”.
Implementation rules (do not reinvent):
1. Reuse existing architecture only:
- `BaseUITestCase`
- `UITestID` and accessibility identifiers
- screen objects under `Tests iOS/Screens/`
- wait helpers (`tapWhenReady`, `waitForExistence`, `waitForDisappearance`, etc.)
2. No `sleep(...)`.
3. No raw/localized text selectors as primary locators.
4. Add missing accessibility IDs only when required, then wire them through current helper patterns.
5. Keep tests deterministic with fixtures and launch flags from `BaseUITestCase`.
6. Follow existing naming/style conventions from current passing tests.
7. Add screenshots at meaningful checkpoints for triage.
Flake-resistance checklist (must satisfy):
- Each test has deterministic starting state (fixture + launch args).
- No arbitrary timing waits.
- Assertions target stable identifiers.
- Test does not depend on current date text formatting unless already stabilized by existing helpers.
- If a new selector is needed, add app-side accessibility identifier first.
Deliverable shape:
- Prefer one suite file with 3 test methods, unless existing suite placement is clearly better.
- Method naming: `test<Feature>_<Behavior>()`.
- Keep helper logic in screen objects/helpers instead of duplicating in test body.
Validation gates (required before done):
1. Run only the 3 new tests (not full suite), e.g.:
- `xcodebuild -project Feels.xcodeproj -scheme "Feels (iOS)" -destination 'platform=iOS Simulator,name=iPhone 16 Pro' -only-testing:"Tests iOS/<SuiteName>/testA" -only-testing:"Tests iOS/<SuiteName>/testB" -only-testing:"Tests iOS/<SuiteName>/testC" test`
2. If failures occur, fix and rerun until green.
3. Run the same targeted command a second time to check flakiness.
4. Only mark complete if both runs pass.
Output format:
1. Selected QA test IDs/names with short reason for selection.
2. Files changed.
3. Key architecture decisions (how existing patterns were reused).
4. Exact test command(s) executed.
5. Run results for pass #1 and pass #2.
6. Any residual risk/gaps.