Describe the Red-Green-Refactor cycle in Test-Driven Development

WHAT THIS TESTS: This question tests your understanding of Test-Driven Development (TDD) as a software design methodology, not just a testing strategy. The interviewer is looking for more than a simple definition; they want to see that you grasp the purpose and design implications of each step. A senior candidate should connect TDD to concepts like interface-first design and long-term code quality.

A GOOD ANSWER COVERS: A strong answer outlines the process in order. First, mention the vital initial step: creating a list of test cases to guide development. Second, describe the Red step: write a single test for the next piece of functionality, and watch it fail. This proves the test works and defines what you need to build. Third, explain the Green step: write the absolute minimum amount of functional code required to make the test pass. The goal is just to pass, not to write perfect code. Fourth, detail the Refactor step: now that the functionality is working and tested, improve the structure of both the new and existing code to keep it clean and well-designed.

COMMON WRONG ANSWERS: The most common red flag, as noted by Martin Fowler, is neglecting or downplaying the Refactor step. Candidates who do this treat TDD as just a way to get test coverage, ending up with a "messy aggregation of code fragments" that happen to have tests. Another mistake is describing the Green step as writing the final, production-quality code. The point of the Green step is speed and simplicity, with quality improvements deferred to the Refactor step. Finally, forgetting the initial step of creating a test list shows a less mature understanding of how TDD guides the overall design process.

LIKELY FOLLOW-UPS: Expect questions like "What are the benefits of writing the test first?", "How does TDD help with software design?", or "When would you choose NOT to use TDD?". A senior candidate should be ready to discuss how TDD forces a focus on the public interface (API) of a class before its implementation, and how sequencing the tests is a key design skill.

ONE CONCRETE EXAMPLE: Imagine adding a sum(a, b) function. First, you'd list tests: positive numbers, negative numbers, zero. For Red, you'd write test_sum_positive_numbers() asserting sum(2, 3) == 5. This fails because sum doesn't exist. For Green, you might write def sum(a, b): return 5. The test passes. It's dumb, but it passes. Now, add a new Red test: test_sum_with_one_negative() asserting sum(5, -2) == 3. The first test still passes, but the new one fails. For the next Green, you change the implementation to def sum(a, b): return a + b. Now both tests pass. For Refactor, you'd look at the code. Here, it's clean. In a real scenario, you might rename variables or remove duplication.