views:

94

answers:

4

Are there any guidelines when quoting estimates for projects/tasks involving 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?

+1  A: 

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

Carl Manaster
+3  A: 

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.

Pascal Thivent
+1  A: 

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.

JeffH
A: 

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.)

quamrana