test-driven-development

Test-driven development writes failing tests first, then minimal production code to pass them, then refactors while keeping tests green. This Red-Green-Refactor cycle ensures behavior is verified before implementation, reducing bugs and technical debt by anchoring code to explicit test requirements.

Red-Green-Refactor is a three-step loop: write a failing test (red), write minimal code to pass it (green), then clean up while tests stay green (refactor). This enforces small, focused implementations backed by tests that document actual behavior and prevent regressions.

Yes. Test-driven development applies to all feature work, bug fixes, and refactors. Write a test that reproduces the bug or specifies the refactor goal, watch it fail, implement the minimal fix or change to pass it, then refactor to keep the suite green.

TDD enforces a mandatory failing test before any production code is written. This constraint ensures every feature or fix has explicit test coverage from the start, eliminating untested paths and making behavior transparent through the test suite itself.

After writing a failing test, write only the simplest code necessary to make that test pass—no extra features, no premature optimization. This keeps implementations focused, maintainable, and directly tied to verified requirements.