write-testslisted

# Write tests Test-first authoring of unit and integration tests, one behaviour at a time. End-to-end tests are a separate scope — use the `write-e2e-tests` skill for those; do not duplicate that work here. ## When to use Whenever a piece of behaviour (a function, method, module, or the interaction of a few collaborators without crossing a real network/DB/UI boundary) needs to be implemented or changed, or when the workflow reaches a testing step for unit/integration coverage. ## Method Apply Kent Beck's red-green-refactor loop per behaviour, structuring each test per Meszaros's xUnit Test Patterns: 1. **Pick one behaviour.** Take the next acceptance criterion or edge case not yet covered. If it needs more than one sentence to describe, it is more than one test — split it. 2. **Red.** Write a test that fails for the right reason (the behaviour doesn't exist yet, not a typo or setup bug). Give it a descriptive name stating the behaviour and condition, e.g. `returns_empty_list_when_input_is_empty` or `throws_when_amount_is_negative` — not `test1` or `testFoo`. 3. **Structure with Arrange-Act-Assert** (Bill Wake / Beck): set up inputs and collaborators (Arrange), invoke exactly the one thing under test (Act), check the outcome (Assert). No conditionals, loops, or try/catch-as-control-flow inside a test — a test with logic in it is itself untested code (Meszaros, *Obscure Test*). Prefer one focused assertion or a tight cluster checking one outcome; avo