Red-green-refactor

Write one failing test, make the smallest change that passes it, then clean up without turning the tests red again.

“write a failing test then make it pass”“the TDD loop”“test first then clean up”“watch it fail before coding”“red green refractor”“why would I write a test before the code exists”“fail pass clean up”“one test at a time workflow”

What it is

Red-green-refactor is the three-beat loop inside test-driven development. Red: write one test and watch it fail for the expected reason. Green: write the smallest change that makes it pass. Refactor: improve the design without changing behavior while the suite stays green. Kent Beck popularized the loop through Extreme Programming and wrote it up as the spine of 'Test-Driven Development: By Example' in 2002.

Reach for it when behavior can be expressed as small examples: a parser rule, pricing calculation, permission check, or a bug you can reproduce. The deliberately tiny steps keep feedback close to the code that caused it, and the red step proves the new test is capable of catching something.

Gotcha: skipping any color breaks the loop. A test that starts green may assert the wrong thing; writing a whole feature before going green loses the narrow feedback; never refactoring leaves a pile of minimum-effort code. Refactor structure only after behavior passes, then rerun the whole suite.

Ask AI for it

Implement <behavior> with Vitest using strict red-green-refactor cycles. For each acceptance example, write one arrange-act-assert test, run it and confirm the expected assertion failure, add only enough production code to pass, then remove duplication and improve names while rerunning the full suite. Record the red failure and green result for every cycle, and do not add implementation before a failing test requires it.

You might have meant

test driven developmentunit testarrange act assertregression test