test-driven-development

Test-driven development enforces writing a failing test before any production code. Start by writing a test that fails, observe the failure, write minimal code to pass it, then refactor. This Red-Green-Refactor cycle ensures tests verify actual behavior and prevents untested code from reaching production.

Writing tests first catches design flaws and edge cases before implementation, ensuring tests verify behavior rather than passing for wrong reasons. Tests written after code often validate existing logic rather than requirements, missing bugs that test-first would surface immediately.

Yes. Test-driven development applies to new features, bug fixes, refactors, and behavior changes. Write a failing test that reproduces the bug or specifies the refactor's outcome first, then implement the minimal fix or change to pass it, preventing regressions and overengineering.

By enforcing failing tests before code, test-driven development catches bugs early in development rather than in production or late testing phases. This eliminates premature optimization, overengineering, and design flaws that would require extensive debugging later.

Test-driven development strictly prohibits production code without a failing test first. The workflow enforces the no-production-code-without-a-failing-test rule, ensuring code quality and preventing untested features from entering the codebase.