Backend Test Patterns

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 duplicate.
• For read-modify-write logic (increment a counter, transition a status field), consider what happens if two requests interleave. If the code relies on an optimistic-locking version check or a database-level atomic operation, test that the loser of the race gets a clear conflict response rather than silently clobbering the winner's update.
• These don't always need true multi-threaded tests — simulating the interleaving directly (e.g. issuing the two writes in the order a race would produce, or asserting the query includes the guard condition it needs) is often enough to catch the bug without a flaky concurrency test.