Testing Fundamentals

What Is Test-Driven Development (TDD)?

Test-driven development (TDD) is a software development methodology where tests are written before the production code, following a red-green-refactor cycle: write a failing test, write the minimum code to pass it, then refactor.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

In Depth

TDD inverts the traditional workflow. Instead of writing code and then testing it, developers start by writing a test that describes the desired behavior. The test fails (red). Then they write just enough code to make the test pass (green). Finally, they clean up the code while keeping the test passing (refactor).

This cycle repeats for every small piece of functionality, building up the codebase incrementally with comprehensive test coverage as a side effect. TDD naturally produces well-tested, modular code because each function is designed to be testable from the start.

TDD is primarily a developer practice, but QA engineers benefit from understanding it. Teams that practice TDD tend to have stronger unit test suites, which means QA can focus on higher-level testing (integration, E2E, exploratory) rather than catching basic functional bugs. QA engineers who understand TDD can also participate in test design conversations earlier in the development process.

Why Interviewers Ask About This

Interviewers ask about TDD to gauge your understanding of software development practices. Even if you don't practice TDD yourself, knowing the concept shows you can collaborate effectively with development teams that do.

Example Scenario

A developer building a password validator writes tests first: must be 8+ characters (red → implement → green), must contain uppercase (red → implement → green), must contain a number (red → implement → green). After the red-green-refactor cycles, the validator has 100% test coverage and handles all edge cases.

Interview Tip

Explain the red-green-refactor cycle clearly. Acknowledge TDD's benefits (high coverage, better design) and limitations (slower initial velocity, not ideal for UI code). If asked whether you practice TDD, be honest — understanding it matters more than claiming to use it daily.