TDD Refactoring Cycle Vocabulary

Red-green-refactor is the TDD heartbeat: (1) Red — write a test for behaviour that doesn't exist yet, run it, watch it fail (proving the test is valid); (2) Green — write the simplest code that makes the test pass; (3) Refactor — improve the code's structure, readability, and design while ensuring all tests remain green. Then repeat.

In TDD, the failing test's error message acts as the next development instruction. If the test fails with 'method calculateTax does not exist', you create that method. If it fails with 'expected 42 but got 0', you implement the calculation logic. The test failure message drives each small step — it's a live specification of what needs to be built.

Test-first writing has several benefits: the test failing first proves it's a real test (not a vacuous always-passing test); it forces you to think about the API and expected behaviour before getting lost in implementation; and it ensures every line of production code exists to satisfy a specific test — preventing over-engineering.

'Under green tests' means all tests are passing before you start refactoring. The safety net of green tests is what makes refactoring safe — if you break something during refactoring, a test will immediately turn red and tell you exactly what broke. Never refactor under red (failing) tests — you won't know if your refactoring caused a new failure or if it was pre-existing.

Testability and good design are closely linked. If a class is hard to instantiate in a test, it probably has too many dependencies. If a function is hard to test in isolation, it's probably doing too much (violating single responsibility). TDD practitioners say 'listen to the tests' — when tests are painful to write, it's a signal to refactor the design, not the tests.