Project Implementation estimates with TDD

Are there any guidelines when quoting estimates for projects/tasks involv开发者_高级运维ing TDD?

For example, when compared to normal development of a task taking 1 day to complete, how much more should a TDD driven task take? 50% more time or 70% more time? Are there any statistics available, assuming the developer is well versed with the language and the test framework?

To my experience, writing tests takes as much time and sometimes even more time than development (i.e. add from 100% to 150% more time) but drastically reduce the time spent for bug fixing. Here are some Studies Of Test Driven Development. Also have a look at this paper.

The difference is high at first, decreases with experience, but is probably always a factor

The difference in implementation time between conventional coding and TDD will decline as the developer becomes better at TDD. TDD beginners, and even intermediates, are likely to get caught-up deciding what tests to write and/or will write more tests that end up being thrown out after refactoring. With experience, a TDD'er will become more efficient, as they become better and quicker at choosing what tests to write

I'm not sure what the absolute lower limit of the ratio of conventional to TDD is. I'd guess 1:1.5, but I can't believe that most developers can ever test-drive code as fast as they could just write code, much less write code then write tests.

And as others have said, a significant payoff for that extra time spent doing TDD is that debugging time is vastly reduced for test-driven code.

Coding time should be about the same as testless development. Debugging time should be reduced by approximately 99%.

Another payoff when producing code with TDD is that the tests written become a regression suite. The tests then make these activities much more safe:

• Refactoring after the fact.
• Further development of the same code.
• Bug fixing.

(NB wrt Bug Fixing, I remember a couple of times where either I'd forgotten to implement a couple of cases or there were late additions to the spec, the additional development was a doddle with tests in place.)

If you want a mathematical answer, my finding has been has been time spent in test : production is 2:1 (conservative - majority of time spent in test is THINK time). However you can't apply a 3X factor to your current (non-TDD) estimates because TDD helps you make steady progress.. you don't spend time

• coding up things you don't need
• running in circles of break and fix. OR breaking existing features.
• a distinct bug-find and fix phase at the end
• Near-zero attach the debugger and step thru sessions

Off the top of my head, I'd go for a 2X on your existing estimates.