Practice TDD refactoring cycle vocabulary: red-green-refactor, test-first development, making tests pass, refactoring under green, and how tests drive design.
0 / 10 completed
1 / 10
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 / 10
'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 / 10
'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 / 10
'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 / 10
'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.
6 / 10
During a code review of Alice's PR for the user authentication service, Bob comments: 'This test is overly specific – it's checking for a particular error message. Shouldn't we be testing the *outcome* of the authentication attempt?' What does Bob likely mean in the context of TDD and refactoring?
Bob is highlighting an over-engineered test. In TDD, tests should focus on *what* the system should do, not *how* it does it. A specific error message test can become brittle and difficult to maintain as the underlying implementation changes. The goal is a robust test that validates the desired outcome without being overly prescriptive.
7 / 10
You're working with David on a refactoring task for a legacy API endpoint. He asks: 'I've just added a new test that passes. Should I immediately start improving the code to make it more efficient?'
David's question reveals a misunderstanding of the core principle: 'green' means the existing functionality works. Refactoring should *always* be done under the protection of passing tests. Changing the code without ensuring the test still passes introduces risk and can break previously working functionality – it's vital to maintain the 'green' state before making improvements.
8 / 10
Sarah sends this Slack message during a discussion about refactoring a complex data model: 'We need to ensure that our tests are 'under green' before we even *think* about improving the model's structure.' What does Sarah mean?
Sarah correctly emphasizes the importance of 'green' as a safeguard. 'Under green' signifies that the existing functionality – in this case, the data model and its associated tests – remains intact. Refactoring should *never* introduce breaking changes; the tests provide continuous validation during the process.
9 / 10
You're reviewing a PR description for a refactoring of a payment processing service. The author writes: 'Refactored the transaction logic to improve performance and reduce latency.' What aspect of TDD is *most* relevant in this context?
While performance improvements are valuable, TDD prioritizes validating *behavior*, not just metrics. The tests should ensure that the core business rules (e.g., successful payment processing) still hold true after the refactoring. Focusing solely on latency without adequate behavioral tests risks introducing regressions.
10 / 10
During a standup meeting, Mark says: 'I've been writing tests *before* I implement the code. It's really helped me to think about the requirements and design upfront.' What is Mark describing?
Mark is accurately describing the Red-Green-Refactor cycle – a core tenet of TDD. This iterative process starts with writing a failing test (Red), implementing just enough code to make the test pass (Green), and then refactoring the code for efficiency and clarity while maintaining the green status.
What will I learn from the "TDD Refactoring Cycle Vocabulary" exercise?
Practice TDD refactoring cycle vocabulary: red-green-refactor, test-first development, making tests pass, refactoring under green, and how tests drive design.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this TDD/BDD Language exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss tdd/bdd language topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more TDD/BDD Language exercises?
See the full TDD/BDD Language exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.