Test-Driven Development Phrases: Red-Green-Refactor Language
5 exercises on TDD vocabulary and the red-green-refactor cycle. Choose the most natural and professional option.
0 / 10 completed
1 / 10
In TDD, what is the correct first step in the red-green-refactor cycle? Choose the most professional phrasing.
Let's write the failing test first: This is the defining principle of TDD — you write a test before any production code. The test must fail initially (the "red" phase) to confirm the test is valid and that the feature doesn't already exist. Options B and D describe the opposite of TDD, writing tests after implementation, which is the traditional approach TDD was designed to replace. Option C suggests a passive audit rather than driving development through tests. In TDD conversations, this phrase signals discipline and signals to teammates that the process will be followed correctly.
2 / 10
After making a test pass in TDD, what should you do next? Which phrase best captures this?
The test is now passing — time to refactor: In the red-green-refactor cycle, getting the test to pass (green) is only the second step. The third step — refactoring — is equally important: you clean up the code, remove duplication, improve naming, and ensure the design is sound, all while keeping the tests green. Option A skips refactoring entirely. Option B conflates "passing tests" with "ready to deploy." Option D makes a logical error — passing tests guarantee behaviour, not code quality. Saying "time to refactor" demonstrates a mature understanding of TDD as a design discipline, not just a testing strategy.
3 / 10
You want to say that tests should verify observable behaviour rather than how the code works internally. What is the best phrasing?
I want to assert on the behaviour, not the implementation: This phrase captures a key TDD and unit-testing principle: tests should verify what a unit of code does from the outside, not how it achieves it internally. Implementation-coupled tests break every time you refactor, even when the behaviour is unchanged. Option A is close but imprecise — tests do care what the code does, just not how. Option C conflates "public API" testing with behaviour testing, which is slightly different. Option D is too casual and doesn't reflect the principled distinction being made. Using "assert on the behaviour" is idiomatic in professional testing discussions.
4 / 10
A test directly inspects private variables and internal function calls. How would you flag this problem professionally?
This test is too coupled to internals: "Coupled to internals" is the standard professional term for tests that depend on private methods, internal state, or implementation details rather than observable outputs. Such tests become a maintenance burden — any refactoring breaks them even when the feature still works. Option A is informal and vague. Option B phrases it as a question without stating the problem clearly. Option C is reasonable but less precise — "coupled to internals" is more concise and widely understood. In code reviews and TDD coaching, this phrase pinpoints the anti-pattern without ambiguity.
5 / 10
Your code under test calls an external API. You want to replace the real API with a test double. Which phrase is most appropriate?
Let me mock the external dependency: "Mock" is the standard term in unit testing for a test double that replaces a real dependency — such as an HTTP client, database, or third-party API — with a controlled substitute. Mocking allows tests to run in isolation, deterministically, and without network calls. Option B uses "fake," which is a different test double type (a working simplified implementation), and the phrasing is informal. Option C ("disable") is vague and doesn't suggest a testing pattern. Option D avoids the problem entirely. Saying "mock the external dependency" precisely identifies the technique (mock) and the subject (an external system), which is exactly how experienced developers communicate in TDD sessions.
6 / 10
During a code review of Alice's new user authentication module, Bob comments: 'This test seems to be deeply intertwined with the implementation details. It's checking if user.get_password() returns a string. Shouldn't tests focus on verifying that users can successfully log in?' What is the most appropriate response Alice could provide to Bob?
Alice needs to articulate the core principle of TDD – focusing on *observable* behaviour. Option 1 is a reactive response without explanation; option 2 misrepresents the test's purpose, and option 3 ignores Bob's concern. Option 4 best captures the desired shift towards user-centric validation.
7 / 10
You are writing a PR description for a new feature in your e-commerce platform's payment processing service. The tests now include assertions about the response codes returned by the external payment gateway API. Which of the following phrases best describes how you should frame this change to ensure it aligns with TDD principles?
This scenario highlights the importance of framing test descriptions around *verification* rather than implementation. Option 1 is too vague. While options 3 and 4 touch on integration, option 2 specifically mentions 'verifying' the gateway's response codes – a key aspect of TDD when dealing with external dependencies.
8 / 10
Charlie is struggling to write tests for his logging service. He keeps writing tests that directly check the contents of log messages instead of verifying that the logs are being generated under specific conditions. David suggests: 'You're testing the implementation, not the behaviour!'. What phrase does David use to best describe this issue in a professional context?
David's phrasing directly addresses the core problem: testing implementation details. Option 1 is too judgmental; option 2 highlights fragility but doesn't pinpoint the root cause. Option 4 suggests a different technical issue. The correct phrase focuses on the fundamental TDD principle of verifying observable behaviour.
9 / 10
During a Slack conversation about a failing test in the user profile service, Emily says: 'The test is failing because the database connection isn't being properly closed after the operation. We need to add an assertion to verify that the connection is closed.' What's the most appropriate follow-up comment from you, focusing on TDD?
This scenario demonstrates how TDD guides troubleshooting. Emily's initial response focuses on fixing a technical detail (connection closing). The correct answer immediately proposes writing a *test* that *verifies* the desired behaviour—ensuring the connection is closed—a core element of red-green-refactor. This shifts the focus to observable validation.
10 / 10
You are preparing a standup update on your work. You've been using TDD to develop a new API endpoint for retrieving product data. During the development process, you've used mocks to isolate the endpoint from external dependencies. Which phrase best describes how you approached this task within the context of TDD?
This question examines the strategic use of mocking. While mocks can speed up development, the key is that they are used *during testing* to isolate and verify behaviour. Option 1 describes a non-TDD approach. Option 3 accurately reflects the TDD methodology – using mocks to create a testable environment. The final option prioritizes efficiency over verification.
What will I practise in "Test-Driven Development Phrases: Red-Green-Refactor Language"?
This module focuses on Phrasebook — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Phrasebook exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around phrasebook — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Phrasebook exercises?
See the Phrasebook hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.