docs: TESTING.md + TEST_RULES.md for the isolation/domain model

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>
This commit is contained in:
Trey T
2026-06-05 16:37:05 -05:00
parent abc98c8fa8
commit 7cdd88b11a
2 changed files with 87 additions and 2 deletions
+2 -2
View File
@@ -15,7 +15,7 @@ These rules are non-negotiable. Every test, every suite, every helper must follo
## Independence
8. **Every suite runs alone, in combination, or in parallel** — no ordering dependencies
9. **Every test creates its own data in setUp, cleans up in tearDown**
9. **Every test gets its OWN isolated account**`AuthenticatedUITestCase` mints a fresh Kratos identity per test (`uit_<domain>_<uuid>@test.honeydue.local`), seeds under its own token, and deletes it in tearDown (cascading all data). Never share an account across tests.
10. **No shared mutable state** — no `static var`, no class-level properties mutated across tests
## Clarity
@@ -29,4 +29,4 @@ These rules are non-negotiable. Every test, every suite, every helper must follo
16. **Target: each individual test completes in under 15 seconds** (excluding setUp/tearDown)
## Preconditions
17. **Every test assumption is validated before the test runs** — if a task test assumes a residence exists, verify via API in setUp. If the precondition isn't met, create it via API. Preconditions are NOT what the test is testing — they're infrastructure. Use API, not UI, to establish them.
17. **Seed UI-gated preconditions BEFORE login** — a fresh account is empty at login, so data the UI must display has to be seeded before the app loads it. Use `requiresResidence` (seeds a residence) or override `seedAccountPreconditions(_:)` to seed a full scenario via API. Preconditions are infrastructure, not what the test is testing — establish them via API, never UI.