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

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.

The red-green-refactor loop is meant to be tight, often only a few minutes per cycle. The first failing test should describe the smallest meaningful behaviour. The implementation should do the simplest thing that turns the test green, even if that means hard-coding a return value temporarily. The refactor step is where design emerges: extracting helpers, removing duplication, renaming for clarity, while the test suite guarantees behaviour does not regress.

TDD is sometimes confused with BDD (behaviour-driven development) and ATDD (acceptance test-driven development). All three put tests first, but they differ in scope and audience. TDD operates at the unit level, written by developers for developers. BDD describes user-facing behaviour in plain language (Gherkin) so business stakeholders can collaborate. ATDD frames the work around acceptance criteria agreed before development begins. A team can practice all three at different layers of the same product.

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 and pair with developers on edge cases that unit tests should cover.

Common criticisms of TDD include slower initial velocity (writing tests before code feels backwards at first), poor fit for UI work where the visual design is being explored, and the risk of over-specifying internal implementation in tests that then break during refactoring. Experienced TDD practitioners counter these with discipline: keep tests focused on behaviour rather than implementation, and accept the up-front cost in exchange for the long-term confidence to refactor.

WHY IT MATTERS

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

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.

TIP

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.

FAQ

Frequently asked questions.

What does TDD stand for?

TDD stands for Test-Driven Development, a software development methodology where automated tests are written before the production code that satisfies them. The full cycle is often described as red-green-refactor: write a failing test, write the minimum code to make it pass, then refactor while keeping the suite green.

What is the red-green-refactor cycle?

Red-green-refactor is the core loop of TDD. Red: write a small test that describes the next bit of behaviour and watch it fail. Green: write the simplest possible code that makes the test pass, even if the code is naive. Refactor: improve the design (extract helpers, rename, remove duplication) while keeping every test passing. Each cycle is meant to be tight, often only a few minutes.

What is the difference between TDD and BDD?

TDD (test-driven development) operates at the unit level and is written by developers for developers, focused on internal behaviour. BDD (behaviour-driven development) describes user-facing behaviour in plain language (often Gherkin scenarios) so business stakeholders, developers, and QA can collaborate on what the system should do. A team can use both: TDD inside the implementation, BDD scenarios that anchor acceptance tests at the feature level.

What are the benefits of test-driven development?

TDD produces high test coverage as a side effect, encourages modular and testable design, and gives developers confidence to refactor because regressions surface immediately. The discipline of writing the test first also forces clearer thinking about requirements and edge cases before code is written, which often surfaces ambiguity earlier than traditional workflows.

What are the drawbacks of TDD?

TDD has a learning curve and can feel slower in the short term, particularly for developers new to the practice. It is awkward for visual UI work where the design is still being explored, and naive TDD can over-specify internal implementation in tests that then break during refactoring. Experienced practitioners counter this by keeping tests focused on behaviour, not on internal call patterns.

Should QA engineers practice TDD?

Most TDD is done by developers because it lives inside production code. QA engineers do not typically write the failing test for a new function, but understanding TDD matters in interviews and in collaboration. Teams that practice TDD tend to have stronger unit suites, which lets QA focus on integration, E2E, and exploratory work. SDETs in particular are often expected to practice TDD on their own automation framework code.

Is TDD still relevant in 2026?

Yes. TDD remains the dominant test-first methodology for unit-level code in 2026, particularly in backend and SDK work. Modern variations include property-based TDD (using libraries like Hypothesis or fast-check) and AI-assisted TDD where tools generate the implementation suggestion after the developer writes the test. The core red-green-refactor discipline has not changed.