One of the most valuable development practice that has become popular recently is test-driven development. When done correctly, unit tests can dramatically drop the cost of maintaining software while increasing its value. All the things that management wants and needs from the processes that are built around software development are embodied in this simple practice including consistency, reliability, and quality.

Code that has good unit tests tell us that it's working correctly now and also tells us it's working correctly in the future. Tests allow us to not only exercise the code in exactly the same way the application uses it but also documents its usage so we know exactly what to expect from the software that we write. Unit tests are contracts that express the expectations of the software they're testing. Having a suite of unit tests in place for code allows us to automate a great deal of regression testing.

We need to eliminate the regression testing delay between the time a developer writes a defect and the time it takes to identify it. If our regression tests can identify defects then we must run them frequently to get rapid feedback. With this immediate feedback we can begin to see that many software development practices are not so good. Even with a very rudimentary continuous integration system and coarse-grained tests, developers can get immediate feedback on integration errors and thereby rapidly reduce the time to correct.

Developers begin to write code differently and that improves the quality of the system being built. Development teams that use continuous integration also build software differently and if they have good unit tests they have a high confidence that their code works as expected. Continuous integration with a reliable suite of unit tests is perhaps the most important practice to implement of all the Agile practices and it possibly provides the greatest value.

But as valuable as unit tests are for the software we write, they are even more valuable in the process of designing the software in the first place. The practice called test-first development has developers write a test even before they write a line of production code. It turns out that writing the test first is an incredibly valuable discipline for designing testable software and has become widely adopted within the development community.

I want to stress that test-first software development, contrary to its name, is really not about testing. Test-first software development is about designing software so that it is testable and understandable. Test-first software development is one of the more advanced development practices. It requires that the team understand and use the discipline for building software.

A lot of developers say to me that they don't have time to write test code as well as production code but it turns out that doing test-driven development, even though you are writing significantly more code, is often far faster in the long run because of the things you are not doing.

Doing TDD, I spend far less time debugging code because my tests find problems in my code before then can become defects. I also spend less time reading and interpreting requirements because my tests allow me to build code with concrete examples, which is often more straightforward than trying to write code from abstract requirements. Most importantly, my tests give me confidence that my code still works correctly when I refactor or enhance my software and there's no way to overestimate the value that confidence gives us.