A bug fix starts with a test that reproduces the bug through the public operation, and that test is the regression test. Reduce the failing input first (see reduction). See it red without the fix: run it on the faulty commit (disposable worktree) or with only the fix reverted, and check the failure line comes from the assertion, not from setup or an import error. A test never seen red protects nothing.
Tests live in their own file, never inline. In Rust, foo.rs declares #[cfg(test)] mod tests; with the tests in foo/tests.rs (or foo_tests.rs through #[path]), never an inline mod tests { … } block. Keep the same split in every language. When the user's own project inlines tests, move the inline tests of a module you change, and report it. In a project the user does not own, follow its layout unless the user asks (see test layout).
Take expected values from the contract, never from running the code under test, the same formula, the current output, or a snapshot. A user's guessed cause is evidence, not an expected value.
Do not mock the unit under test. Replace only collaborators that are slow, dangerous, unavailable, or nondeterministic; use the real object for pure functions and value objects, and the real engine (an isolated database or file system) for engine semantics such as constraints.
No assertion-free tests, and no assertion that only checks "did not raise". After a failing operation, assert what it left behind (files, rows, messages), because a bug can raise the same exception.
No snapshot rubber stamps: never regenerate a snapshot or golden file to get green. Normalize only what varies, and review every diff.
No fixed sleep as synchronization. Inject a clock, force the thread interleaving with a barrier, or poll with a deadline and report the last state. Every wait has a deadline.
Assert outcomes through the public operation, not private helpers, storage, call order, or counts, unless the call is the contract. Tests that break on refactors that change no behavior are change detectors.
One behavior per test, with the action visible in the body, so a failure names one rule.
Do not weaken assertions, skip tests, add retries, or lengthen timeouts to get a green run. Diagnose, and report unexplained failures.
In a tests-only task, do not fix production code; report the failing behavior.
Do not touch devices, flash firmware, or call live services without explicit approval. Run the narrower layer and label it.
When the project already has a mutation tool, run it on the changed functions (see generative) and classify each survivor as a missing test, a weak assertion, or an equivalent mutant. Otherwise report it as not run and do not add one without approval.

Workflow

Write the contract; map each claim to the smallest layer that can observe it. For a bug, the contract is the expected behavior, and the reduced reproduction is the first test.
Choose inputs: classes and boundaries, a decision table, transitions, standard vectors, or properties.
Write the tests, then run them where the behavior is missing and record the red line.
Make the change, rerun the test and its neighbors.
Report each claim with its layer, the commands run, and what was not run.

Scripts

python3 scripts/ddmin.py [--fail-status N] [--fail-text TEXT] [--unit line|char] [--output FILE] [--json] INPUT -- CMD ARGS {} reduces a failing input to a 1-minimal one, with the oracle as argv and {} for the candidate path; it prints units N -> M, oracle runs K. Exit 0 on success, 1 when the input does not fail the oracle, 2 on usage errors. On Windows, use py -3 for python3. Run python3 scripts/test_ddmin.py after changing it.

References

Read test design when choosing expected values, boundaries, or a layer, when picking a mock, stub, or fake, when a test breaks on every refactor, when deciding where a test file goes, or for package, host, and hardware claims.
Read reduction when shrinking a failing input, config, or program, writing the oracle for ddmin.py, measuring an intermittent failure, or packaging a reproduction.
Read regressions and flakiness when fixing a bug, for races, timeouts, expiry, tests that pass alone and fail in the suite, or before deleting a test.
Read generative for property tests, fuzzing untrusted input, sanitizers, or judging test strength with mutation testing.
Read diagnosis when the cause of a failure is unknown, when several causes are plausible, for hangs, native crashes, file, network, or build errors, failures after running a while, or a limit the tool should not have.

write-behavior-tests

Write Behavior Tests

Rules