test-driven-development

Test-driven development enforces writing failing tests before implementing code. Write a minimal failing test describing desired behavior, run it to confirm failure (RED), implement the simplest code to pass (GREEN), then refactor. This cycle applies to features, bug fixes, and refactoring across any project.

RED/GREEN/REFACTOR is a three-phase test-first workflow: RED means writing a failing test, GREEN means writing minimal code to pass it, and REFACTOR means improving code while tests stay green. This cycle ensures tests drive design, prevents regressions, and produces simpler, well-scoped APIs.

Test-first development builds a regression safety net by creating tests that guard against future changes breaking existing behavior. Every feature and fix gets a failing test first, ensuring coverage exists before implementation and protecting the codebase as it evolves.

Yes. Test-driven development applies to feature work, bug fixes, refactoring, and behavior changes. For bugs, write a failing test that reproduces the issue, then fix the code to make it pass. For refactoring, tests verify that behavior remains unchanged while you improve the implementation.

Test-driven development is a workflow discipline, not framework-specific. The RED/GREEN/REFACTOR cycle works with any testing framework, language, or platform. The core requirement is writing failing tests before implementation, regardless of your tech stack.

Test-first development writes failing tests before any implementation, letting tests drive design decisions and ensuring comprehensive coverage. Writing tests after code often results in tests that merely validate existing logic rather than guiding design, missing edge cases, and creating weaker regression protection.