Test driven development

[Roel Schroeven]

Virgil Dupras schreef:
> On Jan 24, 1:30 pm, Roel Schroeven <rschroev_nospam... at fastmail.fm>
> wrote:
>> 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
> 
> I also have a book about TDD and it never was of much help either. All
> techniques come from the initial workflow: Red - Green - Refactor.
> 
> The problem you describe is a tricky problem. The way I feel it should
> be solved is:
> 
> - Write spam() (and its tests, of course).
> - Then, at some point, in the re-factor phase, you split extract the
> function ham() from spam(). Alright, do it and keep the tests as is
> (all on spam()).
> - Then at some other point, you extract eggs(). same thing.
> - After a while (I don't know, 3 or 4 milestones), when it becomes
> clear that ham() and eggs() are there to stay, start moving your tests
> away from spam() by just mocking ham() and eggs() and just make sure
> that spam() call them with the right arguments. The tests you had on
> spam() that were relevant to ham() and eggs() are just performed
> directly on them now.
> 
> What I've been saying in my other message is: Don't do that too early,
> because if it turns out that ham() and eggs() is not the optimal way
> to do it, but foo() bar() and baz() is, it is *much* easier to do a
> safe re-factoring with high level tests.

That sounds reasonable. I'm getting the impression that reading that 
book led me to a too strict approach.

I guess I just need to try somewhat harder to use TDD in my daily 
coding. Apart from books, are there other resources that can help 
beginners with TDD? Mailing lists, forums, newsgroups possibly?

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

Roel Schroeven