What is Test-Driven Development (TDD)?

Most engineers learn to program by writing code and then, if there's time left over, checking whether it works. Test-driven development turns that order on its head. You write a small test that describes what the code should do before the code exists, watch it fail, then write just enough code to make it pass. Done in a tight loop, this single habit changes how you design, how confidently you refactor, and how much of your code ends up exercised by tests.

TDD is one of those ideas that sounds almost too simple to matter and turns out to reshape the way you build software once it sticks. This guide walks through what it actually is, the rhythm you follow, a worked example you can type out yourself, and — because it is a question every team eventually asks — how TDD relates to code coverage and where it fits in safety-critical work.

What is test-driven development?

Test-driven development is a workflow in which every change to production code is preceded by a test that the change is meant to make pass. Instead of treating tests as something you add afterward to prove the code works, TDD uses tests as the specification you write first. The test states, in executable form, what "working" means for the next small slice of behaviour.

That reframing matters. A pile of prose requirements can be vague or contradictory; a test cannot. It either passes or it fails, and it does so the same way every time you run it. A suite of well-written tests becomes an executable specification — a description of intended behaviour that the machine can check on every commit. When someone later asks "what is this function supposed to do?", the answer is the tests, and the answer is never out of date because the build would have caught it.

TDD is usually practised at the unit level — one function, one class, one small behaviour at a time — but the discipline it instils (state the goal, then meet it) scales up to larger designs too.

The red-green-refactor cycle

The engine of TDD is a three-step loop you repeat dozens of times a day. Each pass is small — often only a few minutes — and the names come from the colour your test runner shows you.

Then you loop back to red for the next behaviour. The discipline is in the order and the size: never write production code without a failing test asking for it, and never let a refactor proceed without green tests guarding it.

A test you haven't watched fail is a test you can't trust — it might be passing for the wrong reason.

A worked example

Theory only goes so far, so let's build something tiny. Suppose we need a function fizzbuzz(n) that returns "Fizz" for multiples of 3, "Buzz" for multiples of 5, "FizzBuzz" for multiples of both, and the number as a string otherwise. We'll do it in Python with pytest.

We start in red. Before any implementation exists, we write a test describing the simplest behaviour:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz

def test_plain_number():
    assert fizzbuzz(1) == "1"

def test_multiple_of_three():
    assert fizzbuzz(3) == "Fizz"

Now we move to green: the smallest code that passes both assertions. We don't handle 5 yet, because no test asks for it.

# fizzbuzz.py
def fizzbuzz(n):
    if n % 3 == 0:
        return "Fizz"
    return str(n)

# $ pytest -q
# ..                                      [100%]
#  2 passed

From here you loop: add a red test for fizzbuzz(5) == "Buzz", make it green, add one for fizzbuzz(15) == "FizzBuzz", make it green, and so on. Each new behaviour arrives test-first. When the logic gets repetitive, the refactor step is where you fold the conditions into something cleaner — and the existing tests guarantee you didn't break the cases you already covered. Every line of fizzbuzz exists because a test demanded it, which has a pleasant side effect we'll look at next.

TDD and code coverage

Because every line of production code in pure TDD is written to satisfy a test, you tend to end up with high coverage almost by accident. You never wrote a branch that no test asked for, so there's little untested code lying around. That's a genuine benefit — but it invites two myths worth dispelling.

First, high coverage is not the same as TDD. You can reach 95% coverage by writing all your tests after the fact; the number says how much code ran during tests, not whether tests drove the design. Second, TDD does not guarantee strong coverage criteria like MC/DC. A test-first habit gets you statement and branch coverage cheaply, but it says nothing about whether each condition in a compound decision was independently exercised — the kind of analysis that MC/DC for DO-178C demands.

The healthier way to think about it: TDD is how you build behaviour; coverage is the safety net that shows you what your tests missed. You write tests first, and then a coverage tool reads the truth back to you — which lines, branches and conditions your suite actually touched, and which it quietly skipped. The two are complementary, not interchangeable. A code coverage tool turns "I think I tested everything" into a number you can defend.

TDD in safety-critical code

In avionics, automotive and medical software, testing is not a matter of taste — standards like DO-178C and ISO 26262 spell out what evidence you must produce. TDD fits naturally here because it pairs so well with requirements-based testing: when each requirement becomes a failing test you then satisfy, you build traceability from requirement to test to code as a by-product of how you work.

But TDD does not replace the structural coverage analysis those standards require. The standards ask you to demonstrate that your requirements-based tests exercised the code structure to a defined criterion — statement, decision, or MC/DC depending on the assurance level — and to justify anything left uncovered. TDD helps you write those tests in the first place; it does not by itself prove the criterion was met. You still need a coverage tool to measure structural coverage on a build made with the same compiler that ships, and an analysis of every gap. TDD and structural coverage analysis are two different jobs that happen to reinforce each other.

Benefits and limits

TDD earns its reputation for a handful of concrete reasons:

• Design feedback. Writing the test first forces you to use your code before it exists. Awkward setup or a confusing signature shows up immediately, when it's cheap to change.
• Regression safety. A growing suite means every future change is checked against everything you've already built. Refactoring stops being scary.
• Living documentation. The tests describe intended behaviour in executable form, and the build guarantees they never drift out of date.
• Small, verifiable steps. Working in minutes-long red-green-refactor loops keeps you out of long, unverified debugging sessions.

It is not a silver bullet, and it's worth being honest about the limits:

• It is not a substitute for coverage analysis. Feeling thorough is not the same as measuring what you exercised. You still need the report.
• It is not integration or system testing. Unit-level TDD says nothing about how components behave together, under load, or against real hardware and timing.
• It has a learning curve. Test-first feels slow at first, and writing testable code is a skill. The payoff comes once the habit is fluent.

Getting started with TDD

The fastest way to learn TDD is to do one tiny cycle, on real code, today. A few practical tips to make the first week stick:

1. Pick a small, pure function to start — something with clear inputs and outputs and no I/O. FizzBuzz, a string formatter, a validation rule. Save the gnarly stateful code for when the habit is solid.
2. Always watch the test fail first. The red bar is what proves the test is real. If it passes immediately, you didn't write a meaningful test.
3. Write the dumbest code that passes. Cleverness is for the refactor step. Getting to green quickly keeps the loop tight.
4. Pick a unit-testing framework and learn its basics — pytest for Python, GoogleTest for C/C++, JUnit for Java, and so on. Our roundup of unit testing tools for C, C++, Java and C# is a good place to choose one.
5. Run a coverage report after a session to see what your test-first habit actually exercised — and to find the branch you forgot to write a test for.

The bottom line

Test-driven development is less a testing technique than a way of designing software one small, verified step at a time. Write the test, watch it fail, make it pass, clean it up, repeat. The discipline produces code that is exercised by tests almost as a side effect, gives you the confidence to refactor, and leaves behind an executable specification that never goes stale.

Just don't mistake the high coverage TDD tends to produce for proof that your tests are complete. TDD is how you write good tests; a coverage tool is how you find out which lines, branches and conditions they still missed. Practise the first, measure with the second, and you'll have both well-designed tests and the evidence to back them up.