testinglisted

# Testing Design tests that increase confidence, survive refactors, and reflect real usage. ## Reference Map - Read [references/strategy.md](references/strategy.md) when deciding what to test, how much to test, or how to prioritize coverage. - Read [references/fundamentals.md](references/fundamentals.md) when you need the core mental model for assertions, frameworks, isolation, and useful failures. - Read [references/interaction-testing.md](references/interaction-testing.md) when testing user-visible behavior, flows, or observable system interactions. - Read [references/quality-gates.md](references/quality-gates.md) when deciding how static checks, automated tests, manual checks, and delivery gates should work together. - Read [references/mocking.md](references/mocking.md) when dealing with stubs, spies, mocks, randomness, or flaky external boundaries. - Read [references/glossary.md](references/glossary.md) when the user asks about testing terminology. ## Defaults - Test behavior through public interfaces. - Follow a testing trophy bias: lean on static checks and integration tests, with fewer unit and end-to-end tests. - Prefer a few high-value integration tests over many shallow micro-tests. - Mock only real boundaries: network, time, randomness, payments, third-party APIs. - Choose assertions a user, caller, or downstream system would care about. - Keep tests deterministic, small, and readable. ## Workflow 1. Identify the highest-risk behavior or workflow. 2. Pick th