test-driven-development

Test-driven development begins by writing a failing test for the desired behavior, writing minimal production code to pass that test, then refactoring for readability. This Red-Green-Refactor cycle eliminates untested code and reduces technical debt.

The Red-Green-Refactor cycle is a strict test-first workflow where you write a failing test, implement minimal code to make it pass, then refactor the code. It ensures tests validate real behavior before implementation across all software engineering tasks.

Yes, test-driven development applies to bug fixes, refactoring, and behavior changes, not just new features. It enforces writing a failing test that reproduces the bug or validates the new behavior before modifying any production code.

Common test-driven development anti-patterns include testing mock behavior instead of real behavior, adding test-only methods to production code, and writing tests after implementation. Strict adherence to the test-first workflow prevents these software testing mistakes.

Writing tests after implementation increases technical debt because it often validates existing code rather than desired behavior, leading to untested edge cases and unplanned regressions. Test-first development ensures code is built to pass specific behavioral validations.