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 -- http://mail.python.org/mailman/listinfo/python-list
