testing-tiers
Testing Tiers
A decision discipline for keeping a test suite green and meaningful. A green suite that proves nothing is worse than a failing one you trust — this skill keeps the two apart. It applies to any project with tests; the tier names below generalize across frameworks (the concrete names like "vitest" or "jest" are placeholders for whatever the project uses).
The defining constraint: tests must exercise the real entry path and verify the world, not the component's self-report. A mock-heavy unit suite can be 100% green while the shipped behavior is broken — the failure mode this skill exists to prevent.
The tiers, and when each applies
Pick the shallowest tier that would actually fail for the change's regression:
| Tier | What it proves | Applies when |
|---|---|---|
| Unit | A function/class behaves per its contract | The behavior is confined to one module |
| Integration | Several modules cooperate | A shared contract or wiring changes |
| Real entry path | The shipped entry (loader, binary, server, worker) actually works | A product-visible plugin, entrypoint, or composition changes |
| End-to-end | The assembled system works against a real external boundary | The change touches provider, network, or cross-system behavior |
| Snapshot | External contract / presentation output stays stable | Model-, protocol-, or human-visible output changes |
Match evidence to the surface: focused unit tests for behavior, snapshots for model or user-visible output, real-entry-path tests for shipped entrypoints, and e2e for provider behavior. Never default to the full suite for a narrow change — run the smallest set that covers the diff, and let CI own exhaustive coverage.