Test Driven Development (TDD) is a method of development where the test for each piece of functionality is written before the functionality is written; and then iteratively the functionality is fleshed out only within the limits of the tests written for it.
Put another way: No test, no feature, and no feature beyond the tests written.
There are deeper mechanics behind that idea; (mechanics commonly referred to as red, green, refactor).But, that’s the gist of it.
Test Driven Development helps with the following problems:
- Murky problem space
- Ensuring architecture is easy to change when the business needs new functionality not considered at initial design time
- confidence for your development team in making future changes without regression bugs
- developing software more accurately and quickly
And a non-reason to adopt TDD, but often stated: 100% test code coverage
Most times teams try to bolt on TDD and get
through problem #1 and #2, and never make it over the hump for problem
#3, but the long term benefits are #4 and #5. Imagine if a year from now
you could ask your team to add new functionality and not have to worry
about whether or not there is a subtle bug that destroys your customer’s
confidence in your work. That’s pretty powerful.
But, TDD isn’t useful in all contexts, for
all teams, for all reasons. Teams that have a slow rate of requirements
change or feature change (averaging less than 1 feature per person per
unit of release time) won’t benefit as much as teams that have a higher
rate of change. Teams that don’t have the infrastructure to support
Continuous Improvement (Automated builds) won’t benefit until they have
CI in place.
TDD isn’t a short term win for productivity or speed of development; it takes several iterations of concerted practice to get even small teams to the point where it changes how they think of developing software in a way that enables better TDD practices; but if teams stick with it, and have guided help during the rough times with TDD, the medium and long term benefits to the business are worth it.
TDD isn’t a short term productivity hack, it’s a good way to reduce cost of change, cost of unplanned development work, and the cost of a lack of confidence in making changes to your system when the customer wants something new or different.