mdlockyer/behavioral-testing
Tests that can actually fail. Writing guidance (expected values from the spec, proof the test fails on the bug, no silent test edits, no building to the test), a test-suite audit that proves weak tests with surviving mutants, a gated repair flow, and fail-to-pass bug reproduction. Five worker agents and two hooks.
Write tests that can actually fail — expected values from the spec, not from running the code; evidence the test fails on the bug and not only passes on the fix; no silent changes to tests; no satisfying the check instead of the request. Use whenever writing, fixing, strengthening, or reviewing tests of any kind, whenever a feature or bug fix needs tests, when a failing test tempts you to change it, when a passing test is about to be treated as proof, and when asked to "add coverage".
Turn a bug report, issue, failing scenario, or suspected defect into a fail-to-pass reproduction test with proof that it fails on the current code for the right reason and would pass on any correct fix. Use when asked to "reproduce this bug", "write a failing test for this issue", "prove this is broken", "add a regression test for the fix", when a fix is about to be written and there's no red test yet, or when a code audit has a candidate finding that needs confirming. Not for writing feature tests (use behavioral-unit-testing).
Audit a test suite for tests that cannot fail, tests that pass on the bug, tests that enforce wrong behavior, tests pinned to one implementation, and flaky tests; prove each finding with a surviving mutant; report with coverage and stop for approval. Use when asked to audit, review, grade, or assess tests or a test suite, when someone says "are these tests any good", "do our tests actually catch bugs", "why did this ship with green tests", "check our test quality", or before trusting a suite as an oracle for other work. Not for writing new tests (use behavioral-unit-testing) or fixing them (use test-repair).
Repair tests that a test audit found weak, flaky, pinned to one implementation, or suspicious, with proof for every change: a surviving mutant that now dies, a revert that now goes red, or a shuffled run that now agrees. Use after a test audit when the user approves findings, or when asked to "fix these tests", "strengthen the assertions", "make this test actually test something", "un-mock this", or "fix the flaky tests". Never silently changes what a test asserts; tests that enforce suspicious behavior are escalated, not rewritten.