diff --git a/docs/architecture/overview.md b/docs/architecture/overview.md index 22c8802..352435d 100644 --- a/docs/architecture/overview.md +++ b/docs/architecture/overview.md @@ -42,6 +42,7 @@ monorepo plan is prepared alongside it. - No ad-hoc randomness for gameplay; use deterministic RNG - Keep domain logic independent of endpoints or UI - Prefer clear Korean comments in core gameplay logic for maintainers +- Test strategy and layering: `docs/testing-policy.md` ## Runtime Processing (Outline) diff --git a/docs/testing-policy.md b/docs/testing-policy.md new file mode 100644 index 0000000..e0f0715 --- /dev/null +++ b/docs/testing-policy.md @@ -0,0 +1,55 @@ +# Testing Policy (Draft) + +This document summarizes the testing strategy for the Sammo/HiDCHe repository. +The key is to separate "DB behavior emulation" from "state/logic/flow validation" +so each layer is tested with the right scope. + +## Core Principles +- Prefer Repository/DB Port interfaces over ORM mocks; split implementations: + - InMemory Repository (Fake) + - Real DB Repository (e.g., Prisma) +- Validate domain constraints in the logic layer where possible; DB constraints + act as a secondary safety net. +- Use deterministic seeds for all gameplay-impacting RNG. + +## Test Layers + +### 1) Constraint Tests +Goal: ensure constraints (unique/foreign key/check) behave consistently in +both InMemory state and the DB. + +- Unit tests: validate domain constraints with InMemory repositories. +- Integration tests: verify the same violations fail in the real DB. +- Mock target: InMemory Repository (Fake). +- Use real DB only in integration tests. + +### 2) Game Logic / Command Tests +Goal: verify state input -> state output and that flush behaves as expected. + +- Unit tests: run logic against InMemory state and assert outputs. +- Integration tests: execute the same command and confirm DB persistence. +- Mock target: InMemory Repository (Fake). +- "Send to DB" behavior is validated via real DB tests. + +### 3) Turn Flow Tests +Goal: verify the end-to-end scheduler/turn processing flow. + +- Nature: integration/system tests. +- Stack: Real DB + (test) Redis. +- RNG uses fixed seeds for determinism. +- Keep a small set of smoke/regression scenarios due to cost. + +### 4) Scenario Build Tests +Goal: ensure scenario parsing and DB application are correct. + +- Unit tests: parse/validate scenario files (map size, ID collisions, ranges). +- Integration tests: load scenarios into a test DB and verify key tables. + +## Result Composition Guidelines +- Unit tests: fast, wide coverage. +- Integration tests: focus on real DB/Redis behavior. +- Smoke tests: minimal coverage of turn flow/build/scenario loading. + +## MockDB Conclusion +- "InMemory Repository (Fake)" is more practical than an ORM mock. +- DB-level behavior (constraints/transactions/locks) belongs to integration tests.