82 lines
1.9 KiB
Markdown
82 lines
1.9 KiB
Markdown
# Testing layers between unit and integration
|
|
|
|
## Unit tests
|
|
Test a single function or class in isolation.
|
|
|
|
- No real dependencies
|
|
- Everything external is mocked or stubbed
|
|
- Very fast, very granular
|
|
- Good for pure logic
|
|
|
|
**Goal:** Verify correctness of small, isolated units
|
|
|
|
---
|
|
|
|
## Sociable unit tests
|
|
Units are tested together with their close collaborators.
|
|
|
|
- Multiple classes/functions work together
|
|
- Only external side effects are mocked (DB, network, filesystem)
|
|
- Internal collaborators are real
|
|
- Still fast, but more meaningful than isolated units
|
|
|
|
**Goal:** Verify local collaboration without infrastructure
|
|
|
|
---
|
|
|
|
## Component / Module tests
|
|
Test a coherent group of units as one component.
|
|
|
|
- Entire module is tested as a black box
|
|
- Internal structure is irrelevant
|
|
- Boundaries are mocked, internals are real
|
|
- No real infrastructure
|
|
|
|
**Goal:** Verify that a module behaves correctly as a whole
|
|
|
|
---
|
|
|
|
## Service / Slice tests
|
|
Test a full use case or service flow.
|
|
|
|
- Domain + application logic is real
|
|
- Adapters are mocked or faked
|
|
- Represents a real business action
|
|
- Often maps to one command/query
|
|
|
|
**Goal:** Verify business behavior without infrastructure cost
|
|
|
|
---
|
|
|
|
## Contract tests
|
|
Test the contract between two components or services.
|
|
|
|
- Focus on inputs/outputs and schemas
|
|
- No real integration required
|
|
- One side is mocked, contract is enforced
|
|
- Prevents breaking changes
|
|
|
|
**Goal:** Verify that boundaries remain compatible
|
|
|
|
---
|
|
|
|
## Integration tests
|
|
Test real integration with infrastructure.
|
|
|
|
- Real database, filesystem, network, etc.
|
|
- Slower and more expensive
|
|
- Fewer tests, higher confidence
|
|
|
|
**Goal:** Verify that the system works with real dependencies
|
|
|
|
---
|
|
|
|
## End-to-end (E2E) tests
|
|
Test the system exactly like a user would.
|
|
|
|
- Everything is real
|
|
- UI → backend → infrastructure
|
|
- Slow and fragile
|
|
- Very few tests should exist
|
|
|
|
**Goal:** Verify critical user flows |