From: Peter Szinek <peter@...>
Date: 2006-12-05T21:45:35+09:00
Subject: TDD/unit testing question

Hello,

Slightly OT, but since I think Unit testing/TDD is a commonly accepted 
methodology here, I'll give it a shot:

I am writing a web extraction framework in Ruby which is now relatively 
big. I am doing kind of a semi-TDD (i.e. some things are done pure TDD, 
and I am writing tests later for stuff which are not) - so at the end 
everything should be covered by tests.

I have also tons of black-box tests (i.e. for the specified input and 
output, yell if the output of the current run is different) and as the 
code grows, also a great load of unit tests.

My problem is that since the code is being changed a lot (sometimes 
quite brutal refactoring, even dropping some classes, joining others, 
throwing out inheritance hierarchy to replace it with composition or 
vice versa) my development time is 20-30% (maybe more) of updating all 
the tests (which is kinda annoying) and the remaining to actually write 
the code.

Anyway, I have trapped so much errors when running all the tests between 
refactorings that the overall development time is much more faster than 
if I had to bug-hunt for all the obscure weirdness that popped up and 
catched easily by the tests. I guess this will be even more true as the 
code will grow.

So my question is not if I have to follow these practices or not but rather

1) Am I doing something wrong? (i.e. that I spend so much time with 
rewriting/modifying/updating the tests? or is this normal)
2) Are there some tools/methods/ideas to speed things up? Or this is 
just good so?
3) Maybe I am just too new to these techniques and a skilled TDDist 
marches much faster?

I have seen people (now I am concretely talking about Java coders, but 
language does not matter) who left TDD/writing lots of unit tests 
because of this (and of course because of a boss  who wanted a solution 
quickly and did not care about long term problems )

What do you think?

Peter

__
http://www.rubyrailways.com