142 lines
2.5 KiB
Markdown
142 lines
2.5 KiB
Markdown
# 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. |