What Is Test-Driven Development (TDD)? A Practical Intro

Most developers learn to write code first and tests later, if there is time. The trouble is, there rarely is. Tests get skipped, bugs slip through, and eventually the codebase becomes something everyone is scared to change.

Test-driven development flips the order. You write a test before the code it checks, watch it fail, then write just enough code to make it pass. It sounds backwards at first, but done well it gives you a safety net of tests, cleaner designs and the confidence to change code quickly.

This intro walks through the red-green-refactor cycle with a simple example, covers what research says about the costs and benefits, and gives an honest view of when TDD is worth it and when it isn’t.

Test-driven development in one paragraph

Test-driven development (TDD) is a software development practice popularized by Kent Beck, described in his 2002 book Test-Driven Development: By Example. Instead of writing a large chunk of code and testing it afterward, you work in tiny loops. Each loop adds one small piece of behavior, defined first by an automated test. Over time, the tests become both a specification of what the code should do and a regression suite that catches anything you break later.

The red-green-refactor cycle

TDD is usually summarized in 3 steps:

1. Red: Write a small test for the next bit of behavior. Run it and watch it fail. The failure proves the test actually checks something.
2. Green: Write the simplest code that makes the test pass. Don’t worry about elegance yet.
3. Refactor: Clean up the code, removing duplication and improving names and structure, while keeping all tests passing.

Then repeat, usually every few minutes.

In a December 2023 article called “Canon TDD”, Beck added an important starting step: write a test list first. Brainstorm the behaviors and edge cases the change should cover, then turn exactly one item into a real test at a time. As you work, add newly discovered cases to the list. When the list is empty, the feature is done.

Key takeaway: TDD is not “write all the tests first”. It is a tight loop: 1 small failing test, the simplest code to pass it, then a cleanup, repeated until your list of behaviors is done.

A worked example: a shipping cost calculator

Imagine an online store with a shipping rule: orders of $50 or more ship free, otherwise shipping costs $5.99. Here is how TDD might build it in Python with pytest.

Test list:

• Order under $50 pays $5.99 shipping.
• Order of exactly $50 ships free.
• Order over $50 ships free.
• Negative order totals are rejected.

Red: write the first test and run it. It fails because the function doesn’t exist yet.

```python from shipping import shipping_cost

def test_order_under_50_pays_standard_shipping(): assert shipping_cost(20.00) == 5.99 ```

Green: write the simplest thing that passes.

python def shipping_cost(order_total): return 5.99

That looks silly, but it is deliberate. The next test will force real logic.

Red again:

python def test_order_of_exactly_50_ships_free(): assert shipping_cost(50.00) == 0

Green:

```python FREE_SHIPPING_THRESHOLD = 50.00 STANDARD_SHIPPING = 5.99

def shipping_cost(order_total): if order_total >= FREE_SHIPPING_THRESHOLD: return 0 return STANDARD_SHIPPING ```

Continue the list. Add a test for an order over $50 (it passes immediately, which is fine; it documents the rule). Then add a test that a negative total raises an error, watch it fail, and add the check.

Refactor: with all tests green, you might rename things, move constants into configuration or switch to a decimal type for money. The tests tell you instantly if the cleanup broke anything.

Notice what happened: the edge case at exactly $50, a classic source of bugs, was considered before any code was written.

What the research says about TDD

TDD has been studied for years, and results are mixed but informative. One frequently cited industrial study, by researchers from Microsoft Research, IBM and North Carolina State University and published in 2008, followed 4 teams: 3 at Microsoft and 1 at IBM. The paper reports that pre-release defect density fell by 40 to 90 percent compared with similar projects that did not use TDD, while the teams estimated that initial development took 15 to 35 percent longer.

That trade-off captures the honest picture of TDD:

• You usually pay more time up front, especially while a team is learning.
• You often get fewer defects and a strong regression suite, which can save time later in debugging, support and rework.

Other studies, especially short experiments with students, show smaller or inconsistent effects. Results depend heavily on team skill, the kind of software and how strictly TDD is practiced. Treat TDD as a powerful technique, not a guaranteed productivity boost.

Benefits and drawbacks

Good tests are a long-term defense against technical debt, because they make it safe to clean up code instead of working around it.

When TDD pays off (and when it doesn’t)

TDD tends to pay off most when:

• Business logic is important and complex, such as pricing, billing, tax rules, eligibility checks or scheduling.
• Bugs are expensive, as in payments, healthcare, finance or anything safety-related.
• The code will live a long time and be changed by many people.
• Requirements are clear enough to describe as examples, ideally from user stories with testable acceptance criteria. See our guide on how to write user stories.
• You are fixing bugs. Writing a failing test that reproduces the bug before fixing it is one of the easiest ways to start with TDD.

It pays off less when:

• You are prototyping to test an idea you may throw away.
• You are working on visual layout where the “right” answer is subjective.
• You are exploring a new library or API and don’t yet know what behavior to expect. Try a time-boxed spike first, then test-drive the real implementation.
• Legacy code has no tests and tight coupling. Start with characterization tests around the area you’re changing, as described in our guide to modernizing a legacy application.

TDD, BDD and testing after the fact

TDD is often confused with related ideas:

• Test-after development: writing tests once code is finished. Better than no tests, but tests tend to be shaped around the existing code and edge cases get missed.
• Behavior-driven development (BDD): grew out of TDD. It describes behavior in business-readable scenarios, often in Given-When-Then form, and is common for acceptance tests.
• Test types: TDD most often produces unit tests, but the same loop can drive integration tests. Our explainer on unit vs integration vs end-to-end testing shows how they fit together.

TDD also pairs well with AI coding tools. Writing the test first gives an AI assistant a precise target and gives you an automatic check on what it generates, which is a safer pattern than accepting large blocks of untested code. Our pieces on AI coding assistants and vibe coding explore that risk.

Where to start with TDD

1. Pick a test framework you already have, such as pytest for Python, Jest or Vitest for JavaScript, JUnit for Java or xUnit for .NET.
2. Start with a bug fix. Write a test that reproduces the bug, watch it fail, fix it, and keep the test forever.
3. Practice on a small, logic-heavy function, like a discount or validation rule, before using TDD on a big feature.
4. Write a test list first and keep each step tiny.
5. Run tests constantly, ideally on every save, and keep the suite fast.
6. Add the tests to your pipeline so every change runs them automatically. See what is CI/CD for how that works.
7. Pair or mob for a few sessions. Working through TDD with a teammate is the quickest way to build the habit.
8. Review after a month. Look at escaped bugs, time spent debugging and how comfortable people feel refactoring.

TDD doesn’t replace other quality work. You still need exploratory testing and release checks like our pre-launch software QA checklist.

Conclusion

Test-driven development means writing a small failing test, making it pass with the simplest code, and refactoring, over and over. It costs extra time up front and takes practice, but for important, long-lived logic it typically repays that with fewer defects, safer refactoring and a test suite that documents how the system behaves. Start small with bug fixes and logic-heavy functions, and expand from there once the habit sticks.

Sources

• Kent Beck: Canon TDD (December 2023) — the test list and the red-green-refactor workflow described by TDD’s originator
• Nagappan et al., Empirical Software Engineering (2008) — the original TDD study of 4 industrial teams
• Microsoft Research: Exploding software-engineering myths — industrial TDD study results on defect density and development time
• pytest documentation: Get started — writing and running tests used in the worked example