Introduction

• Understanding test-driven development
• Being productive with TDD
• When not to use TDD

Software developers are pretty used to the traditional development process. First, they implement. Then, and only then, they test. But why not do it the other way around? In other words, why not write a test first and then implement the production code?

We discuss this well-known approach: test-driven development (TDD). In a nutshell, TDD challenges our traditional way of coding, which has always been “write some code and then test it.” With TDD, we start by writing a test representing the next small feature we want to implement. This test naturally fails, as the feature has not yet been implemented! We then make the test pass by writing some code. With the test now green, and knowing that the feature has been implemented, we go back to the code we wrote and refactor it.

TDD is a popular practice, especially among Agile practitioners. Before I dive into the advantages of TDD and pragmatic questions about working this way, let’s look at a small example.