56 lines
2.1 KiB
Markdown
56 lines
2.1 KiB
Markdown
# 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.
|