test-strategy

# Test Strategy ## Test Pyramid Ratio Guidance ``` /\ /e2e\ ~10% — critical user flows only /------\ / integ \ ~20% — API contracts, DB interactions /------------\ / unit \ ~70% — pure logic, transformations, edge cases /--------------\ ``` Keep the pyramid right-side-up. Inverting it (too many e2e) leads to slow, flaky CI. ## Decision Matrix: Task Type → Test Type | Task Type | Test Type | Tool | |-----------|-----------|------| | Pure function / utility | Unit | Jest / Vitest | | API endpoint | Integration | Supertest / httpx | | Critical user flow | E2E | Playwright | | Data transformation | Property-based | fast-check / Hypothesis | | React/Vue component | Component | Testing Library | | CLI command | Integration | execa + assertions | | Database query | Integration (real DB) | jest + pg / pytest | | Cron job / scheduler | Unit (mocked time) | Jest fakeTimers | ## Mock vs Real Dependency Decision Tree ``` Is it an external API (Stripe, Sendgrid, etc.)? → YES: Always mock. Use recorded fixtures or MSW. Is it a database? → Unit test context: mock (in-memory store or jest.fn()) → Integration test context: real DB (test container or local) Is it the file system? → Mock with memfs or tmp dir, then clean up. Is it time / Date.now()? → Always mock. Use Jest fakeTimers or freezegun (Python). Is it a third-party SDK wrapper you wrote? → Skip testing the wrapper itself, test your code's behavior. ``` ...