What is Test-Driven Development (TDD)?
Quick Answer
TDD is writing a failing test before the code that makes it pass, in a tight loop: Red (write a failing test), Green (write the minimum code to pass), Refactor (clean up with the test as a safety net). It drives design and guarantees the code is testable.
TDD means writing the test first. The cycle is red-green-refactor: I write a test for the behaviour I want, watch it fail, write just enough code to make it pass, and then refactor with the test protecting me. The value isn't really the tests — it's that it forces the code to be testable, keeps units small, and makes me think about the interface before the implementation. It's harder for exploratory or UI work, and if you mock everything it produces brittle tests. I use it for the fiddly business logic and I'm more relaxed about it for plumbing.
- Benefits: high coverage by construction, testable design (small units, clear seams), a regression suite, and it forces you to define “done” before coding.
- Drawbacks / friction: slower initial pace, over-mocked tests coupled to implementation if done poorly, hard for exploratory / UI / algorithmic work.
- Outside-in (start with an acceptance test) vs inside-out (start with the smallest unit).
- You don't have to be dogmatic — many teams write tests immediately after, or use TDD for tricky logic and skip it for boilerplate.