test-driven-development

Test-driven development enforces a RED→GREEN→REFACTOR cycle: write a failing test first, implement minimal code to pass it, then refactor. This approach minimizes diffs, reduces bugs, and ensures every feature has test coverage from the start.

Writing tests first (TDD) clarifies requirements upfront and prevents over-engineering, whereas writing code first risks untested implementations and larger diffs. TDD keeps changes focused to 1–3 files per cycle, making code reviews simpler and catching issues earlier.

Yes. TDD applies to unit tests (small isolated functions) and integration tests (multiple components together). The same RED→GREEN→REFACTOR discipline works across both; you scaffold 1–3 failing tests targeting the smallest slice before writing implementation code.

Refactoring in TDD happens only when tests are green, so you can safely reshape code without breaking functionality. Deterministic test names make it clear what each test verifies, and small focused changes limit the scope of unintended side effects.

TDD works best for well-defined requirements and deterministic logic. It requires discipline to write meaningful tests first and can slow initial velocity. Large, exploratory features may need upfront design before tests can be written effectively.

TDD is less suitable for throwaway prototypes where requirements are unclear. However, once a prototype stabilizes into production code, applying TDD prevents technical debt and reduces rework from quality issues.