Testing

Architecture enables the test pyramid. Clear layers produce correct tests for each layer. Without clear architecture, tests test the wrong things at the wrong level.

Backend: Integration Tests First

Integration tests provide the most confidence per test on the backend. They verify layers work together — repositories, use cases, domain logic — without the fragility of mocking everything.

• Unit tests for pure business logic in the domain layer.
• A backend with only unit tests has gaps at every boundary.
• Focus: unit > integration > e2e, but invest more in integration.

Frontend: E2E Tests First

Most frontend code is rendering and interaction. E2E tests provide more confidence than component unit tests for this.

• Unit tests only for business logic that lives client-side.
• E2E tests are heavy and slow. But for critical user flows — checkout, authentication, onboarding — they are the only tests that verify what users experience.

Testing in the AI Era

Tests shift from catching bugs to defining correctness. They become the contract between past and future changes.

• When AI generates code, passing tests with good coverage provide trust during review.
• Without tests, reviewing AI-generated code is guesswork.
• Quality moves earlier: define what correct means before AI writes code.

Rules

• Match test scope to code scope. Private module → private tests. Domain → unit tests. Infrastructure → integration tests.
• Use beforeEach over beforeAll. Shared state between tests creates flaky tests.
• Use inline snapshots for complex outputs — visible without separate files.
• Test edge cases explicitly. Empty inputs, boundary values, error conditions.
• Verify in dev environment before release. Automated tests are necessary but not sufficient for user-facing changes.
• Question unexpected test modifications in code review.

Evolution

• Feb 2026 — rewritten in rule-oriented format from IDENTITY.md testing philosophy and code review patterns.