harness:test-driven-development

Test-driven development is enforced by requiring a failing test before writing production code, ensuring every feature is validated by real behavior. You write a test that fails, implement the minimum code to pass it, and then refactor.

The red-green-refactor cycle is a strict testing loop: watch the test fail, implement minimally to make it pass, then clean up without adding behavior. This ensures every code change is directly driven by test validation.

Unit tests map to acceptance criteria by using the feature's acceptance_criteria as the source for test coverage. Each test must directly validate a specific criterion, ensuring traceability from requirements through implementation.

Writing a failing test before fixing a bug validates that the test fails for the expected reason, proving the bug exists. You then implement the smallest code change to make it pass, preventing future regressions.

Test-driven development works for refactoring by ensuring behavior is validated before changes. You write failing tests that capture current expected behavior, refactor the code, and verify the tests still pass with pristine output.

You should not use test-first development when behavior cannot be clearly validated or when acceptance criteria are undefined. The approach requires explicit verification that failures happen for expected reasons and implementations pass tests.