Swift Testing
Read docs/TESTING.md and references/testing-patterns.md. Identify test seams before implementation and use tests afterward as one part of the evidence.
Workflow
- Translate requirements into observable behaviour and invariants.
- Test pure domain logic first.
- Inject deterministic service fakes into observable models.
- Cover only applicable transitions: initial, loading, success, empty, failure, retry, cancellation, and stale response.
- Fix IDs, dates, locales, calendars, time zones, and clocks.
- Add isolated integration tests when persistence, network, filesystem, or Keychain adapters are introduced.
- Add UI automation only for critical journeys or behaviour that cannot be verified below the UI.
- Run
make test and make package-build; assemble and manually exercise the macOS application for UI, focus, window, accessibility, entitlement, or bundle changes.
Guardrails
- Use Swift Testing for new tests unless a required framework API needs XCTest.
- Avoid force unwraps and force tries in tests; use
#require or throwing helpers with useful context.
- Do not sleep or depend on wall-clock timing.
- Do not share mutable fixture state between tests.
- Test behaviour rather than private implementation, SwiftUI body shape, or incidental call counts.
- A passing suite does not prove navigation, layout, focus, animation, signing, permissions, or bundle metadata.
- Do not claim generic checklist states as covered unless a test or recorded manual run verifies them.
Output
List behaviour covered, fixtures and dependencies, deterministic controls, commands run, macOS assembly/manual checks, and remaining gaps. A regression fix should include a test that fails without the fix when practical.
1---2name: swift-testing3description: Design, write, or review deterministic Swift Testing coverage for the macOS package's domain logic, observable models, asynchronous dependencies, regressions, and adapters.4license: MIT5---67# Swift Testing89Read `docs/TESTING.md` and `references/testing-patterns.md`. Identify test seams before implementation and use tests afterward as one part of the evidence.1011## Workflow12131. Translate requirements into observable behaviour and invariants.142. Test pure domain logic first.153. Inject deterministic service fakes into observable models.164. Cover only applicable transitions: initial, loading, success, empty, failure, retry, cancellation, and stale response.175. Fix IDs, dates, locales, calendars, time zones, and clocks.186. Add isolated integration tests when persistence, network, filesystem, or Keychain adapters are introduced.197. Add UI automation only for critical journeys or behaviour that cannot be verified below the UI.208. Run `make test` and `make package-build`; assemble and manually exercise the macOS application for UI, focus, window, accessibility, entitlement, or bundle changes.2122## Guardrails2324- Use Swift Testing for new tests unless a required framework API needs XCTest.25- Avoid force unwraps and force tries in tests; use `#require` or throwing helpers with useful context.26- Do not sleep or depend on wall-clock timing.27- Do not share mutable fixture state between tests.28- Test behaviour rather than private implementation, SwiftUI body shape, or incidental call counts.29- A passing suite does not prove navigation, layout, focus, animation, signing, permissions, or bundle metadata.30- Do not claim generic checklist states as covered unless a test or recorded manual run verifies them.3132## Output3334List behaviour covered, fixtures and dependencies, deterministic controls, commands run, macOS assembly/manual checks, and remaining gaps. A regression fix should include a test that fails without the fix when practical.
rcarmo