2.5 KiB
Test layers and where they belong
This section explains where each test type belongs conceptually, based on the rule:
Tests should live as close as possible to the code they verify.
Only boundary- and system-level tests belong to a global test area.
Unit tests
Unit tests belong directly to the implementation they verify.
They protect:
- pure logic
- local decisions
- small transformations
They are part of the code, not a separate concern.
Sociable unit tests
Sociable unit tests belong to small clusters of collaborating units.
They protect:
- collaboration
- shared assumptions
- local workflows
They stay local but are not file-bound.
Component / Module tests
Module tests belong to a module as a whole.
They verify:
- composition
- wiring
- feature-level invariants
- internal boundaries
They run without infrastructure and do not care about internal structure.
They protect correctness of composition.
Service / Slice tests
Service tests belong to business use cases.
They verify:
- orchestration
- business decisions
- multi-step workflows
- cross-module logic (without infra)
They describe what the system does, not how it is built.
They protect business correctness.
Feature flow tests (frontend integration)
Feature flow tests belong to the frontend as a system.
They verify:
- routing
- guards
- navigation
- cross-screen state
- user flows (without real backend)
They run with:
- real frontend
- mocked contracts
They protect frontend system correctness.
Contract tests
Contract tests belong at boundaries between systems.
They verify shared agreements:
- schemas
- semantics
- error shapes
- guarantees
Each side tests the same contract.
They protect compatibility and independent deployability.
Integration tests
Integration tests belong to the system level.
They verify real infrastructure:
- DB
- queues
- storage
- auth
- external APIs
They protect environmental correctness.
End-to-end (E2E) tests
E2E tests belong at the highest level.
They verify:
- critical user journeys
- real deployment
- full wiring
They are few, slow, and intentional.
They protect real-world safety.
Summary principle
- Local tests: unit, sociable, module
- Business tests: service, feature flow
- Boundary tests: contract
- System tests: integration, E2E
The closer a test is to the code, the more of them you should have.
The further away, the fewer — but more meaningful — they become.