test-driven-development

Test-driven development (TDD) is a discipline where you write failing tests before implementing production code, ensuring functionality is verified before deployment. It prevents unverified code from reaching production and catches bugs early, improving overall code quality and reliability.

Red-green-refactor is TDD's core cycle: write a failing test (red), write minimal code to pass it (green), then refactor for clarity. Begin by writing a test for the desired behavior, run it to confirm failure, implement code to pass the test, then improve the implementation while keeping tests green.

Yes. TDD applies to new features, bug fixes, refactoring, and behavior changes. For bug fixes, write a failing test that reproduces the bug, then fix the code to pass it. This ensures the bug stays fixed and documents the expected behavior.

TDD enforces the Iron Law: no production code without a failing test. This rule prevents untested functionality from entering the codebase. Exceptions require human review to ensure deliberate decisions about test coverage and risk.

TDD requires clear test coverage for all new code. You deliver minimal, passing code alongside tests that verify its behavior. Coverage should be sufficient to prevent regressions and document the feature's contract, not necessarily 100%.

TDD writes tests first to define requirements, driving design and preventing untested code. Writing tests after code often misses edge cases and may test implementation rather than behavior. TDD ensures tests guide development from the start.