Agile TDD
Test-Driven Development, or TDD, is a technique where developers write a test before writing the code that passes it. The habit feels backward at first. After a few days, most developers notice that tests guide their design, protect against mistakes, and give them confidence to change code freely.
TDD in Simple Words
Imagine a carpenter who marks the length of a shelf before cutting the board. The mark defines success. The saw follows the mark. TDD works the same way. The test defines what the code must do, and the code follows the test.
The Red, Green, Refactor Cycle
TDD repeats a short three-step loop, often every few minutes.
┌───────────────┐
│ RED │ Write a test that fails
└───────┬───────┘
▼
┌───────────────┐
│ GREEN │ Write the simplest code to pass
└───────┬───────┘
▼
┌───────────────┐
│ REFACTOR │ Clean the code, keep tests green
└───────┬───────┘
│
└──────► back to RED with the next test
Red
The developer writes one small test for behavior that does not exist yet. The test fails, which proves that the test can detect a problem.
Green
The developer writes the least code needed to make the test pass. Elegance can wait.
Refactor
The developer improves names, removes duplication, and simplifies structure. The tests stay green and prove that behavior has not changed.
A Simple Example: Shipping Fee
A store charges a shipping fee. Orders under 50 dollars pay 5 dollars. Orders of 50 dollars or more ship free. A developer builds the rule in small steps.
| Cycle | Test Written | Code Added |
|---|---|---|
| 1 | Order of 20 dollars has a fee of 5 | Return 5 for every order |
| 2 | Order of 80 dollars has a fee of 0 | Return 0 when the total is 50 or more |
| 3 | Order of exactly 50 dollars has a fee of 0 | Confirm the boundary condition |
| 4 | Order of 0 dollars shows an error | Reject empty orders |
Each cycle adds one rule, and the growing set of tests documents the behavior. When a future change breaks the free-shipping rule, a test fails within seconds.
Benefits of TDD
- Fewer defects reach testers and customers.
- Code stays simple because developers write only what the tests require.
- Tests act as living documentation.
- Developers refactor without fear.
- Design problems appear early because hard-to-test code signals poor structure.
Characteristics of a Good Unit Test
- Fast: runs in milliseconds.
- Independent: does not depend on other tests.
- Repeatable: gives the same result every time.
- Clear: the name explains the behavior being checked.
- Focused: checks one behavior only.
Common Mistakes
Writing Large Tests
Large tests fail for many reasons and hide the cause. Small tests point straight to the problem.
Skipping Refactoring
Without cleanup, passing code turns into a tangle. The third step keeps the design healthy.
Testing Everything Through the Screen
Screen tests run slowly. Most tests belong at the unit level.
TDD and Agile Teams
TDD fits inside any Agile framework. Scrum teams include passing tests in the Definition of Done. XP teams treat TDD as a core practice. The automated tests also support continuous integration, since every merge runs the full suite.
Getting Started
- Pick one small feature in a low-risk area.
- Write one failing test and watch it fail.
- Make it pass with simple code.
- Clean the code while tests stay green.
- Practice on small exercises for a few weeks before judging the method.
TDD takes patience, and the payoff grows over time. Developers who practice it build stable products and sleep better before releases.