Practice TDD refactoring cycle vocabulary: red-green-refactor, test-first development, making tests pass, refactoring under green, and how tests drive design.
0 / 5 completed
1 / 5
What are the three phases of the 'red-green-refactor' TDD cycle?
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.
2 / 5
'The failing test guides the implementation.' What does this mean in TDD?
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.
3 / 5
'We wrote the test first then made it pass.' Why is writing the test first important?
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.
4 / 5
'Refactoring under green tests.' What does 'under green' mean and why is it important?
'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.
5 / 5
'The test drove us to a better design.' How can tests improve design in TDD?
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.