testinglisted

# /specseal:testing — put each test where it can actually fail Coverage counts what ran, not what was checked, so a suite can be green and prove nothing. Two questions decide the shape: at which level can this break be observed, and would the test fail if the behavior changed. The pyramid below is general; its middle tier is where projects differ most, so read the examples as one filling. **What sits there is whatever this project's parts have to agree on to work** — a service's database and request handlers, a client's screens against a fake backend, a CLI's argument parsing through to its exit codes, a library's public surface against a real consumer, a pipeline's stages against fixture data. ## Test Pyramid ### Unit Tests (base - most tests here) - Pure functions, business logic - Fast, isolated, no external deps - Mock at boundaries only ### Integration Tests (middle) - Component interactions — the seams this project actually has - Real collaborators where the seam is the point (a test database or container, a fake server, a temp filesystem, a simulator) - Examples by project kind: database queries and request handlers; a screen driven against a stubbed API; argument parsing through to exit codes; a library exercised the way a caller would ### E2E Tests (top - fewest tests here) - Critical user flows only - Login, checkout, core workflows - Slower, run less frequently ## Test Quality Checklist - Tests have descriptive names (should_X_when_Y) - Each test check