Test driven development
rschroev_nospam_ml at fastmail.fm
Thu Jan 24 19:30:47 CET 2008
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
> 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
More information about the Python-list