Test-Driven Development

What is test-driven development?

The old habit is "write it first, test it later." Test-driven development (TDD) flips it: write a failing test first, then write just enough code to make it pass, then refactor to clean things up. This loop is called "red-green-refactor" — red means the test fails, green means it passes.

Why write the test first?

It forces you to define the requirement
Before writing a test, you have to say exactly what the code should do — no guessing as you go.
Every step has a safety net
Each feature has a test watching it. Break something and it goes red immediately, so problems surface early.
It drives better design
To make code testable, you naturally write more modular, loosely-coupled structure.

What's the core loop?

Red
Write a test describing the behavior you want, run it, and watch it fail — that proves the test itself works.
Green
Write the least code to make the test pass. Don't optimize yet.
Refactor
Without changing behavior, tidy the code to be clearer and easier to maintain, with the tests watching your back.

Is it for everyone?

TDD is slower at first, and it can feel tedious for beginners or on exploratory projects where requirements keep moving. But the confidence it buys is worth it: the regression suite is a safety net. On long-lived codebases, backend logic and core algorithms, TDD pays off most.

Bottom line: test-driven development is "set the rule, then write the code" — failing tests push out code that's both correct and clean.