test-driven-development

Test-driven development follows red-green-refactor: write one focused failing test for the behavior, implement the smallest change that makes it pass, then refactor while keeping the test green. Run the narrowest test command at each step and record the evidence.

Skip the failing-test-first loop for documentation-only changes, configuration-only changes, generated files, time-boxed exploratory spikes, and work with no runnable test loop. State the exception explicitly and provide an alternative verification plan instead of skipping coverage.

An unexpectedly passing test means the assertion is too weak or the behavior already exists. Strengthen the assertion or reassess the behavior before changing production code, and never write the implementation first and retrofit a passing test.

Mock only boundaries that are expensive, non-deterministic, externally owned, or unsafe to exercise. Prefer real collaborators when practical, and verify the mock does not replace the behavior under test.

Mark behavior verified only when the chosen test demonstrated its intended failure and then passes after the final implementation change. Run targeted and broader checks, review the final diff, and explicitly report any untested paths.