feat: eslint 적용 및 관련 코드 일괄 수정

docs/testing-policy.md

@@ -5,9 +5,10 @@ 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)
+    - 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.
@@ -15,6 +16,7 @@ so each layer is tested with the right scope.
 ## Test Layers
 
 ### 1) Constraint Tests
+
 Goal: ensure constraints (unique/foreign key/check) behave consistently in
 both InMemory state and the DB.
 
@@ -24,6 +26,7 @@ both InMemory state and the DB.
 - 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.
@@ -32,6 +35,7 @@ Goal: verify state input -> state output and that flush behaves as expected.
 - "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.
@@ -40,16 +44,19 @@ Goal: verify the end-to-end scheduler/turn processing flow.
 - 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.