test-driven-development

Test-driven development (TDD) is a practice where you write a failing test before implementation, run it to confirm failure (red), write just enough code to pass (green), and then refactor. This cycle validates changes and enforces coding discipline.

To apply TDD to refactoring and bug fixes, start by writing a failing test that captures the desired behavior or the specific bug. Then implement the minimal production code required to make that test pass, ensuring the change is validated.

The best way to start TDD for a new feature is to write a failing test for the exact desired behavior first. You then implement only the minimum production code necessary to make that test pass, guaranteeing correctness from the start.

You should never write production code before tests in TDD because the failing test defines the exact requirement and validates correctness. Writing code first breaks the disciplined red-green-refactor cycle and removes the guarantee that changes are tested.

Yes, you can use strict TDD for everyday software development tasks including building new features, performing refactors, and fixing bugs. It enforces the red-green-refactor cycle to ensure all code changes are validated by tests.