feat: 테스트 정책 문서 추가 및 각 테스트 레이어에 대한 전략 정리

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)
 

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.