# SportsTime UI Test Prompt (Paste Into Claude)

Use this when you want Claude to pick and implement the 3 easiest UI tests from QA IDs/names you provide.

Replace the `INPUT` section, then paste the whole prompt.

---

You are an iOS UI test engineer working in the SportsTime repo.

## Mission

From the provided QA cases (IDs/names from `docs/SportsTime_QA_Test_Plan.xlsx`), pick the **3 easiest, lowest-flake cases** and implement solid UI tests for them using the **existing SportsTime UI test architecture**.

## Non-Negotiable Rules

1. Do not reinvent the test framework.
2. Reuse existing architecture:
   - `SportsTimeUITests/Framework/BaseUITestCase.swift`
   - `SportsTimeUITests/Framework/Screens.swift`
   - existing `TestFlows` helpers
   - existing suites under `SportsTimeUITests/Tests/`
3. Prefer updating existing suites over creating new ones.
4. Use stable accessibility IDs already used in the app/tests (`home.*`, `wizard.*`, `tripOptions.*`, `tripDetail.*`, `schedule.*`, `settings.*`, `progress.*`, etc.).
5. Prefer robust waits (`waitForExistenceOrFail`, `waitUntilHittable`) and page-object methods.
6. Avoid `sleep` unless there is no reliable alternative; if used, justify it.
7. Keep tests deterministic with current local test data.
8. Follow naming conventions (`testF###_...`, `testP###_...`, etc.).
9. Do not change product code unless absolutely required for testability (and explain why).
10. Change only what is needed for these 3 tests.

## Required Reading Before Coding

1. `AGENTS.md`
2. `XCUITest-Authoring.md`
3. Existing tests in `SportsTimeUITests/Tests/` for patterns and style

## Selection Strategy (Pick Exactly 3)

Choose the 3 easiest cases using this priority order:

1. Already mostly covered by existing screen objects/flows.
2. Requires minimal or no new selectors.
3. No unstable backend/timing dependency.
4. No complex multi-screen setup unless reusable via existing `TestFlows`.
5. Highest confidence of passing consistently on current simulator baseline.

If a candidate looks flaky/high-risk, skip it and explain why.

## Implementation Workflow

1. Evaluate all candidate QA cases.
2. Output a short ranked list with reason for each.
3. Confirm the chosen 3.
4. Implement tests:
   - Put tests in existing or appropriate suite(s) in `SportsTimeUITests/Tests/`.
   - Add page-object helpers in `Screens.swift` only when reusable.
   - Keep assertions behavior-focused and explicit.
   - Capture screenshots at key checkpoints for longer flows.
5. Run only the 3 selected tests first.
6. Fix failures.
7. Re-run each selected test at least 2 times to catch flake.
8. Stop only when all 3 are green and stable, or clearly blocked.

## Validation Commands

Use this destination:

`-destination 'platform=iOS Simulator,name=iPhone 17,OS=latest'`

Run each selected test explicitly:

`xcodebuild test-without-building -project SportsTime.xcodeproj -scheme SportsTime -parallel-testing-enabled NO -only-testing:SportsTimeUITests/<SuiteName>/test<ID>_<Name> <destination>`

If needed, run selected suite only:

`xcodebuild test-without-building -project SportsTime.xcodeproj -scheme SportsTime -parallel-testing-enabled NO -only-testing:SportsTimeUITests/<SuiteName> <destination>`

Do not run the full suite unless I ask.

## Output Contract

Return:

1. Chosen 3 QA cases and why they were selected.
2. Files changed and what changed in each.
3. Exact commands run.
4. Test results for each selected test (including repeat runs).
5. Any residual risk or blocker.
6. Optional next 2-3 QA cases to implement next (ranked by ease/confidence).

## INPUT (Replace This Block)

Candidate QA cases from `docs/SportsTime_QA_Test_Plan.xlsx`:

- [F-___] 
- [F-___] 
- [F-___] 
- [F-___]
- [F-___] 

Extra constraints:

- [Example: Do not edit `SportsTimeUITests/Tests/TripSavingTests.swift`]
- [Example: Only use existing `TestFlows`]