test-patternslisted

## Purpose A test suite that only exercises the happy path proves the code works when everything goes right, which is the case least likely to break in production. The failure modes — bad input, empty state, concurrent access, partial success �� are where real bugs live and where a thin test suite gives false confidence. This skill is a checklist for deliberately covering that space instead of stopping at the first green run. ## When to use it Any time you write or extend tests for a nontrivial change — new functionality, a bug fix, or a refactor of logic that has any conditional branching. Run through the checklist below as a deliberate step, not an afterthought after the happy-path test already passes. ## Checklist - **Happy path** — the code does the intended thing with valid, typical input. Necessary but not sufficient; don't stop here. - **Boundary values** — empty string/list/collection, zero, negative numbers where they're conceptually possible, the first and last valid index, one-past-the-boundary values that should be rejected. - **Null/missing/malformed input** — `None`/`null`/`undefined` where a value is expected, a required field missing from a payload, a type that doesn't match what's expected, malformed JSON or encoding. - **Failure and partial-failure modes** — what happens when a dependency (network call, database, filesystem) fails outright, times out, or returns a partial/unexpected result. A test that only mocks the success response isn't testing the f