The business value of test-driven development
Most businesses are creating software for one primary reason — to make money. In order to make money, we need software that meets the needs of the business and can be developed and maintained in a reasonable amount of time with a high level of quality. Test-driven development is a discipline that will help you achieve these goals.
Test-driven development involves writing automated unit tests to prove that code is working. The test code is written before the implementation code is written. By writing the tests first, you will know when the code is working once the tests pass. Test names are written as sentences in plain English so that the tests describe what the code is supposed to do. Over time, you will end up with a large suite of automated tests which you can run in a short amount of time. These tests will prove to you that your code is working and will continue to work as you modify or refactor the code base.
Most software applications are intended to be used for many years, and throughout most of their existence, someone will be changing them. The total cost of ownership of an application goes far beyond the cost of the initial effort to create the initial version of the software. The first release is the easy part — you can build the application from the ground up, you don’t have many hindrances, and developers feel very productive. But as time goes on, productivity tends to decrease due to complexity, developer turnover, poor software design, and any number of other reasons. This is where software development really becomes expensive. So much focus is placed on the original cost of building an application without considering how the original development effort will affect the cost of maintaining that application over several years.
Test-driven development can reduce the total cost of ownership of an application. New developers on the team will be able to change the code without fear of breaking something important. The application will have fewer defects (and far fewer major defects), reducing the need for manual QA testing. Your code will be self-documenting because the tests will describe the intended behavior of the code. All of this leads to flexible, maintainable software that can be changed in less time with higher quality.
Software is intended to deliver business value, and test-driven development will help you write higher quality, more maintainable software that can be changed at the fast pace of the business. Test-driven development will lead to successful software projects and enable you to write software that will withstand the test of time.
This is 100% true but there’s an interesting corollary. Contractors that don’t retain code-ownership would tend to find the least use out of TDD. Unfortunately these sort of software shops tend to drive our industry. So then what’s the business value for them to implement TDD practices?
@George,
As a consultant myself, I have to take pride in my work and be disciplined enough to not create a mess for other people to deal with. That’s not something that I want attached to my reputation. :)
TDD helps me quite a bit while I’m developing the application — there is plenty of short term benefit to it. I still need to know that my code is working and that I’m not going to break things.
The benefits you list also come without TDD …
They are provided also by … BDD, POUT, Automated Integration testing and by a good QA department and process
The benefits of TDD are little to do with long term maintenance, but to do with driving out a design in code. Testing is not the important part of TDD … Design is.
That said, I could and would argue that TDD is not a great way of driving out a design for most scenarios, and BDD or even just spiking, would provide a faster and leaner solution, and more long term value
Jon, you need the word “malleable” in this post somewhere.
@George – I’ve done my share of contracting as well, and though the code-ownership is usually short term, you have to have that ownership while you’re writing it because somebody is going to maintain this system after you leave. That somebody could be you at a later date, as well. To operate under the assumption that, “I’m just here a short time, I’ll hack in whatever I need,” is unprofessional.
@jak, I’d argue that TDD is a strong side of the maintenance of a system. You’ve got a strong suite of tests to maintain against, the “safety net” to know you’re not doing damage elsewhere. The practice of TDD is for design, but the result of it does make maintaining an app much easier.