Test-Driven Development: TDD

This is the first post in a series on TDD — something I discovered relatively recently that I think should be fundamental to every development project.

What is TDD?

Test-Driven Development (TDD) is a software engineering practice that combines two things: writing tests first (Test First Development) and refactoring. The typical unit tests are used as the vehicle for writing those tests.

The flow is simple:

1. Failing test — write a test that fails
2. Make it pass — write just enough code to make the test pass
3. Write code — not final code, but acceptable code that satisfies the test; it gets improved in step 5
4. Run the test — if it passes, you know your code does what you think it does
5. Refactor — remove duplication and clean up; re-run the tests throughout to make sure nothing breaks

The goal of TDD is clean code that works. Requirements become tests, and when the tests pass, the software meets the requirements.

Test-driven development is a way of managing fear during programming. Fear makes you tentative. Fear makes you want to communicate less. Fear makes you shy away from feedback. Fear makes you grumpy. — TDD By Example

What are the benefits?

1. You feel more confident about your code and its logic
2. The code ends up cleaner
3. Code quality and maintainability improve
4. TDD tends to produce more modular, flexible, and extensible code
5. Regression testing becomes much easier — automated test cases catch errors early, so you can confidently change code or ship to production

The biggest problem with TDD

TDD doesn’t show its value immediately. You don’t feel the payoff at the start of a project.

You feel it two or three months in, when you need to refactor. That’s when having a comprehensive test suite becomes the difference between a confident change and a terrifying one.

I hope this has been useful. You can read more about TDD on Wikipedia.