# 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.