test-driven-development

Test-driven development (TDD) starts by writing a failing test that specifies desired behavior, then writing minimal code to pass it, and finally refactoring. This red-green-refactor cycle ensures every line of production code is verified by a test before deployment.

Writing tests first prevents bugs by catching issues early, clarifies requirements before coding, and guarantees tests actually verify behavior—since they must fail before implementation. This eliminates rework and builds confidence in your codebase.

Use TDD when implementing new features, fixing bugs, refactoring existing code, or making behavior changes. It applies across projects and ensures changes are robust and well-tested from the start, reducing debugging time.

Yes. TDD works for refactoring and behavior changes in existing code. Write a failing test that captures the desired behavior, implement minimal changes to pass it, then refactor—validating that your modifications don't break existing functionality.

Test-first development (TDD) verifies behavior exists before code ships and catches design issues early. Test-after approaches risk missing edge cases, allow untested code to ship, and often result in tests that validate implementation rather than intended behavior.

Red-green-refactor enforces writing only code needed to pass tests, eliminating bloat. Red (failing test) defines requirements, green (passing code) proves correctness, and refactor improves design—resulting in cleaner, more maintainable code backed by comprehensive test coverage.