Friday, December 3, 2010

TDD Adoption

Many developers I talk to say they have tried TDD, but it “didn’t work for them”. Why is this so often the case? I believe that the main reasons are 1) it wasn’t done correctly 2) the effort was too quickly abandoned 3) the benefits were not obvious to the developer.

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 http://www.pragprog.com/titles/achbd/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 a lot 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

Comments:
I'm a big enthusiastic, defender and practitioner of TDD. I agree with almost everything you sad but i think something was left aside:

Writing Tests takes time.

I know that if you count all the time taken for a particular feature (development time, iterations of bugs found, bugs being fixed, tests run, etc) with TDD will take less time. But we cannot forget that TDD need Source Code to test another Source Code.

What i'm trying to say its that you literally type more when doing TDD. You take more immediate Time. And its really hard to convince anyone about "losing more time now to prevent losing a lot more later" when things are with a tight schedule.

What I think its missing its some easier way to write Tests (specially unit tests). I've being improving some ideas i will try to post on my blog, and i would like to here your opinion also.

Good article by the way, it's good to see we are NOT alone in the universe! :D
 
Post a Comment

Subscribe to Post Comments [Atom]





<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]