test-driven-development

Test-driven development (TDD) catches bugs by writing failing tests first, then implementing minimal code to pass them. This RED-GREEN-REFACTOR cycle ensures every line is validated and tied to a requirement, reducing debugging time and preventing untested code from entering your codebase.

RED-GREEN-REFACTOR is TDD's three-step loop: write a failing test (RED), implement minimal code to pass it (GREEN), then improve the code without breaking tests (REFACTOR). This disciplined cycle ensures robust, maintainable code with complete test coverage from the start.

Fast, isolated, repeatable tests follow Arrange-Act-Assert structure: set up inputs, execute the code, verify outputs. Keep tests independent—each runs alone without side effects—and avoid external dependencies like databases or APIs. This guarantees reliable, self-validating test suites that run quickly and catch regressions.

Yes. TDD guides refactoring by keeping tests in place before you change code. Write tests that reproduce current behavior, refactor with confidence that tests validate your changes, then commit only when tests pass. This ensures refactoring maintains functionality while improving design.

Yes. Write a failing test that reproduces the bug first, then implement the fix to pass it. This ensures the bug is really fixed, prevents regression, and documents the issue. It's a core TDD practice for bug resolution.

TDD writes tests first to drive design and catch gaps; tests written after code often skip edge cases and don't influence architecture. TDD enforces complete coverage, prevents unverified changes, and produces cleaner, more maintainable code from the outset.