test-driven-development

The red-green-refactor cycle drives development by first writing a minimal failing test (red), implementing the smallest code change to pass it (green), then safely refactoring while keeping the test suite green.

Unit testing for bug fixes and refactoring is ideal when you need a reliable, repeatable verification path. You write failing tests to catch the bug, implement the fix to turn them green, and refactor safely under test coverage.

Yes, you can apply test-first development to integration tests. The workflow accommodates any development task where integration tests can verify behavior, requiring you to observe failing tests before implementation and confirm passing after.

To start new feature development with TDD, write a failing test that expresses the desired behavior, run the test runner to confirm it fails, implement the minimal code to make it pass, and re-run the suite to verify.

Observing failing tests before implementing code fixes ensures verification discipline. It confirms the test accurately detects the issue and catches regressions early, increasing confidence in behavioral correctness before minimal passing code is added.

Test-driven development is limited to changes where unit or integration tests can verify behavior. It enforces strict test-first discipline, which may not suit exploratory coding or tasks where reliable, repeatable verification paths are impossible.