tdd

Write the smallest test that encodes the intended behavior and confirm it fails for the right reason before changing production code. Then make the minimal fix, rerun the regression test until it passes, and run nearby validation such as adjacent tests, type checks, or lint.

Skip when the test requires broad harness setup, brittle mocks, slow end-to-end infrastructure, or production-only state. Explicitly explain why the test is impractical and use the closest executable check, such as a targeted script, manual reproduction, or log assertion.

A bad test mostly tests mocks, mirrors current implementation details, depends on timing or unrelated global state, or needs expensive infrastructure for a small fix. Prefer no new test over a bad one and use manual or scripted verification instead.

Make the test deterministic where possible by removing timing dependencies and shared global state, and document the signal being locked down. If the bug exposes a broader failure class, land the focused regression test first, then consider sibling coverage.

Report the failing-before test name and the failure it produced, the passing-after test run, and any nearby validation performed. If failing-before evidence was impossible, state why and describe the closest regression check used instead.