awesome-test-writinglisted

# Test Writing Write tests that fail when the behavior breaks and stay green through refactors. The deliverable is not coverage — it is a tripwire: for every realistic way the code under test could regress, at least one test goes red. A test that cannot fail against broken code is documentation wearing a test's costume. ## When to Activate - "Write tests for X", "add coverage", "this module has no tests". - A bug fix needs its regression test (awesome-bug-fix hands off here). - A review or audit finding says "needs a test" (awesome-code-review, awesome-security-audit, awesome-dependency-audit). - Legacy code needs a safety net before a refactor (characterization tests). Do not activate to review test quality in a diff (awesome-code-review Phase 4 owns that) or to find the root cause of a failure (awesome-bug-fix). ## Work Process 1. Discover the incumbent setup first — runner, assertion style, fixture/factory conventions, file placement, naming pattern. New tests match the repo's existing shape; never introduce a second test framework or a parallel convention. No runner at all → propose the ecosystem default and wait for approval (it is a new dependency). 2. Read the code under test end to end — public seams, inputs, outputs, side effects, error paths. The seam you test through must be one a caller actually uses; needing to export a private function to test it is a design signal to report, not to work around. 3. Choose placement by the lowest level that can catch the de