add-unit-test

Add a unit test

A unit test earns its place when it would fail if the behaviour the acceptance criterion names broke (Kent Beck's "behavioural" and "structure-insensitive" test desiderata). The recurring defect in live runs was not missing test files but tests that never exercised the criterion's own behaviour — they called the function and asserted something incidental, and the reviewer approved.

Procedure

1. Find the unit and its existing tests. Locate the source file and any sibling test. Read one or two existing tests to copy the framework, file naming, location and assertion style (Vitest/Jest/node:test/pytest/JUnit/go test). Call search_lore for the repo's testing conventions. Never add a second framework or runner.
2. Map every AC to the behaviour that proves it. For each criterion write one line: input/state → action → observable outcome. That outcome is what the test asserts. An AC that says "rejects duplicate names" is proven by a duplicate being rejected, not by the create function returning something.
3. Enumerate the cases per behaviour: the happy path, each branch the AC implies, boundary values (0, 1, max, max+1, empty, unicode), and each documented error. If the AC is a rule over many inputs ("round-trips", "never throws"), add a property test (the property-based-test skill).
4. Write the tests. One behaviour per test, Arrange-Act-Assert, a name that states the behaviour (rejects a duplicate name with 409). Include the AC id or wording in the test or describe name so the reviewer can map test → criterion. Use real collaborators when they are fast and deterministic (a "sociable" unit test); substitute only slow, non-deterministic or external ones (network, clock, randomness, filesystem when not the subject).
5. Prove each test can fail (the break-it check). For every AC test, temporarily break the behaviour — invert the condition, return early, drop the write — run the test, see it fail for the right reason, then undo the edit and confirm git diff shows only your intended changes. A test that stays green against broken code is deleted or rewritten. (This is manual mutation testing; where the repo has Stryker/mutmut/PIT, run it on the unit instead. An independent tester never edits implementation files and skips this.)
6. Run the repo's test command from the context packet's verification commands, not the tool directly. Iterate until green. If a test reveals a real bug, fix it only when the ticket scopes it; otherwise note it.
7. Evidence and stop. Use the record-evidence skill: one test_output row per AC naming the command, the pass summary and the test(s) that prove that AC. The runner — not you — submits for review.