test-driven-development

Test-driven development starts by writing a failing test for desired behavior before writing production code. Write a test that fails, then implement minimal code to pass it, then refactor. This red-green-refactor cycle ensures every feature is backed by a test that verifies its behavior.

Write a failing test that reproduces the bug first, then fix the code to pass that test. This approach to bug fixing ensures the issue is genuinely resolved and prevents regression, since the test now guards against the same bug recurring.

Yes. After writing code that passes your tests, refactor for clarity and efficiency while your tests verify behavior remains unchanged. The existing test suite acts as a safety net, confirming refactored code still works correctly.

Test-driven development has exceptions: throwaway prototypes, auto-generated code, and configuration files typically don't require tests written first. For production features, bug fixes, and behavior changes, TDD delivers higher quality and fewer defects.

Writing tests first forces you to think through behavior and edge cases before implementation, catching gaps early. Tests also prevent bugs from reoccurring, reduce debugging time, and create living documentation of expected behavior.

Tests written after code often pass too easily and miss edge cases, since they test what was built rather than what should work. Tests written first—before implementation—define behavior, catch gaps, and ensure code actually solves the problem.