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 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.