backend-test-patternslisted

## Purpose A backend test suite that only exercises the happy path proves the feature can work, not that it's safe. This skill is guidance for rounding out test coverage on the paths that actually cause incidents: bad input, concurrent access, and partial failure — the situations a demo never hits but production eventually will. ## When to use it Whenever you finish implementing an endpoint, service method, or migration-adjacent code path and are writing or reviewing its tests. Especially relevant for anything that mutates state, touches more than one row/table, or could be called concurrently or retried. ## Bad-input coverage - For every field an endpoint accepts, test at least one case of: missing when required, wrong type, out-of-range value, and a value that's syntactically valid but semantically nonsensical (e.g. an end date before a start date). - Test the boundary values, not just clearly-invalid ones — the empty string, zero, the maximum allowed length, a list with one item versus the max allowed items. - Confirm the *response* on bad input, not just that it fails: right status code, error shape matches the rest of the API, and no internal detail (stack trace, DB error text) leaked into the body. ## Concurrency and race coverage - For anything backed by a uniqueness constraint (can't have two of the same thing), write a test that attempts two near-simultaneous creates and confirms exactly one succeeds with a sane error on the other — not a crash or a silent dup