Describe the TDD Red-Green-Refactor cycle

What's really being asked

This question tests if you understand Test-Driven Development as a design discipline, not just a testing strategy. The interviewer is looking for more than a rote definition. They want to see that you grasp how the cycle guides software design, forces a focus on interfaces, and maintains code quality over time. It's a test of your appreciation for the 'why' behind the process, which is critical for a senior developer's perspective on code health.

The full answer

A great answer first mentions the preliminary step of creating a list of test cases, then details the three main steps. First, the Red step: write a single test for the next piece of functionality. It must fail. Its purpose is to define the desired behavior and public interface before implementation. Second, the Green step: write the absolute minimum code required to make the test pass. The goal is not elegance, but speed and focus. Third, the Refactor step: with the safety of passing tests, improve the structure of the code you just wrote and any related code. The purpose is to clean up the implementation without changing its observable behavior.

The mistakes people make

The most common and serious mistake is neglecting or minimizing the Refactor step. This indicates a misunderstanding of how TDD maintains long-term code quality. Another red flag is describing TDD purely as a testing technique, missing its primary benefit as a design tool that forces an interface-first approach. Writing complex, 'correct' code during the Green step is also wrong; the goal is the simplest possible pass. Finally, refactoring while tests are failing (in the Red state) is a procedural error, as you lose the safety net of a known good state.

What usually comes next

Expect questions like: "When would you choose NOT to use TDD?" or "How does TDD impact code coverage?" Another common follow-up is to contrast TDD with Behavior-Driven Development (BDD). You may also be asked how to handle dependencies like databases or external APIs within a TDD workflow, which tests your knowledge of mocks, stubs, and test doubles.

A concrete example

To build a sum(a, b) function, you'd first list test cases. Then, for the Red step, write testSum(1, 2) which expects 3. It fails because the function doesn't exist. For the Green step, you could create the function and simply return 3;. The test passes. Now, add a second test, testSum(2, 3) expecting 5. It fails. To get to Green again, you update the function to return a + b;. Both tests pass. For the Refactor step, you confirm the code is clean and readable. The current implementation is already good, so no changes are needed.