Test driven development

[Roel Schroeven]

Virgil Dupras schreef:
> I know what you mean by top-down vs. bottom-up and I used to have the
> same dilemma, but now I would tend to agree with Albert. Your issue
> with top-down or bottom-up is not relevant in TDD. The only thing that
> is relevant is to reach your current milestone as soon as possible,
> without caring about what you're going to do in the milestone after
> that.
> 
> Not so long ago, I took the "bottom-up" approach to TDD, which was a
> mistake because it leads to over-engineering (the end result is not so
> bad since it's over-engineering that has good test coverage :) )

I don't regularly use TDD yet, and one of the reasons is that in many 
cases I'm unsure exactly how to use it in practice. I read "Test-driven 
development - A practical guide" (and I should re-read), but I feel it 
doesn't help my much in everyday situations. Somehow the examples in the 
book don't match very well with how I code (and I admit that perhaps the 
problem is more with me than with the book).

One of the problems I have is something like what Andy describes: I need 
a function spam(), so I write tests for it. Then I start implementing 
the function and see that I need to write functions ham() and eggs(). 
Should I write unit tests for ham() and eggs(), or do I rely on the 
tests for spam()? If I don't write them, doesn't that make it more 
difficult to find out why the tests for spam() fail?

Speaking about over-engineering, when I do TDD along the lines of the 
book I mentioned, I always feel that I'm over-engineering the tests. It 
all feels very unnatural though I'm convinced it shouldn't be like that.

Can someone suggest other books to read about the subject, ideally 
something more focused on Python or C++ rather than Java?

-- 
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
   -- Isaac Asimov

Roel Schroeven