When shouldn’t my team adopt Test Driven Development?

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.