software-testinglisted

# Software Testing Turn a concrete behavior, invariant, failure mode, or regression risk into the smallest reliable evidence the repository can support. Test the mechanism that decides the behavior directly, then preserve every real boundary that matters to the claim. ## Workflow 1. Read scoped instructions and discover the repository's test layout, commands, frameworks, fixtures, helpers, environments, and nearby examples. Follow those conventions unless they cannot observe the risk. Do not add a test runner, assertion library, crate, or coverage target merely because a generic recipe prefers one. 2. State the claim before selecting a test: the behavior or invariant to protect, the input or state that exercises it, the observable result, and the failure it must distinguish. Separate a known fact from an assumption about a dependency, race, authorization model, or production environment. 3. Choose the narrowest evidence layer that can observe the real risk. Read [Select test evidence](references/select-test-evidence.md) for a behavior and risk model, properties, snapshots, replays, negative proof, and verification of the test itself. 4. Make the decision-carrying mechanism directly testable before considering a double. Read [Modularity and testability](references/modularity-and-testability.md) when policy, transformation, validation, calculation, state transition, or protocol choice is entangled with I/O or framework wiring. 5. Load t