Hi --

Peter Szinek wrote:
> 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?
>
> What do you think?

I sympthize. I think TDD makes more sense for applications in which the
general structure of the program is a given. If youre still working on
the "what's the best API" then you are probably better off just putting
the TDD on the back burner until you have it mostly worked out. Then
you can go back and put in tests. I know that TDD concept promotes
putting the test before the code, and really one should strive to do so
(I don;t do it enough myself) but that doesn't mean you always have to
do so. Really, the most important thing is that you end up with tests.

T.