1.9 KiB
1.9 KiB
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