What Is Test-Driven Development (TDD)?

Q: What is the difference between TDD and unit testing?

Unit testing is a type of test (testing one unit in isolation); TDD is a process for writing any test first. You can do unit testing without TDD, and TDD often produces unit tests — but they're different axes.

Quick answer
TDD is a discipline: write a failing test, write the minimum code to make it pass, then refactor.
The cycle is “red, green, refactor” — and the red step is what forces you to define success first.
It produces code that’s testable by construction, because every feature exists to satisfy a test.

What is TDD?

Test-driven development is a development practice in which you write a test before the code it tests. The test first fails (red) because the feature doesn’t exist, then you write the minimum code to make it pass (green), then you improve the code’s structure without changing behavior (refactor). The tests aren’t an afterthought — they’re the specification of what the code should do, executed.

The red-green-refactor cycle

Red — write a test for a small behavior you want; run it and watch it fail.
Green — write just enough code to pass the test, no more.
Refactor — clean up the code, keeping all tests green.

The cycle repeats in tiny increments, so you always have working, tested code and a growing safety net.

Why it matters

TDD forces you to define “done” before you build — the test is an executable version of the requirement. It naturally yields code that’s modular and testable, catches regressions the moment they happen, and gives you the confidence to refactor. It pairs especially well with a spec, whose acceptance criteria become the tests.

Where this bites vibecoders
The vibecoder’s biggest gap is confidence: when the assistant generates code with no tests, you can’t tell whether your next prompt broke something. TDD (or even just “write tests alongside the feature”) closes that gap. You don’t have to be dogmatic — even a few tests around the critical paths turn “it probably still works” into “the suite says it works.”

Where AI coding assistants get this wrong

Generating code with no tests unless explicitly asked.
Writing tests after the code, which often just assert what the code already does.
Producing tests that pass trivially and check nothing meaningful.
Treating tests as documentation rather than executable requirements.

Checklist

Write the test first for new behavior.
Watch it fail before making it pass.
Write the minimum code to go green, then refactor.
Keep the cycle small and run the suite often.
Use tests as the definition of “done.”

FAQ

Is TDD slower?

In the short term, yes — writing tests first adds upfront time. Over the life of the code, it usually pays back through fewer regressions and easier refactoring. Many teams use a pragmatic middle: TDD for tricky logic, tests-alongside for the rest.

What is the difference between TDD and unit testing?

Unit testing is a type of test (testing one unit in isolation); TDD is a process for writing any test first. You can do unit testing without TDD, and TDD often produces unit tests — but they’re different axes.

Do I need 100% test coverage?

No. Coverage is a signal, not a goal. Aim for tests on the code that matters — business logic, edge cases, security-sensitive paths — rather than a coverage number that can be gamed with trivial tests.