TDD Adoption

1) It wasn’t done correctly.
Doing TDD the right way is beyond the scope of this post. The best ways to learn are pairing with a TDD expert and reading some of the good books on the subject. I really like The RSpec Book and Test Driven.

2) Abandoning the effort too quickly.
At first, development time will increase until proficiency in TDD is obtained. This improvement ravine is very well documented by Martin Fowler.

3) TDD benefits
Though the TDD benefits at the micro-level are significant, the macro-benefits are outstanding! Preventing or fixing bugs early provides a huge cost benefit to the customer. The cost of fixing design or coding bugs exponentially increases with time from bug authoring.

Some argue that the same benefits can be achieved with Test After Development (TAD). In my experience, TDD is much better than TAD for the following reasons:

• Keeps you focused. At any time during the day, you should either be writing a test for a feature or writing code to make that test pass.

• Less code. TDD promotes Do The Simplest Thing That Could Possibly Work (DTSTTCPW). Let’s write code that gets the product delivered instead of frameworks that may or may not ever get used again!

• Necessarily promotes testable code

• FASTER. It’s a lot faster getting it right the first the time! It’s much faster fixing bugs as soon as they are authored

• Testing the feature before it’s implemented tests the intent of the code. When TADing, the intent could have been forgotten

• Very high code quality

• Refactor with confidence. Behavior driven tests ‘protect’ the required features, which means that refactorings should cause test failures

• Thinking of and designing for edge cases up front promotes a better and more stable design