# 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