From: David Chelimsky <dchelimsky@...>
Date: 2007-01-22T11:39:50+09:00
Subject: Re: stub implementations in TDD (was: I don't get rspec)

On 1/20/07, Devin Mullins <twifkak@comcast.net> wrote:
> M. Edward (Ed) Borasky wrote:
> > I do have a bone to pick with the tutorial (or maybe I don't understand
> > TDD/BDD yet). In the stack example, I cringe with horror when I see them
> > setting a method that just returns "true" simply to get a test to pass.
> > That grates on me, because I *know* I'm actually going to have to write
> > the real code eventually. It seems like a waste of time to do the
> > nitty-gritty "add a test to the spec/add a trivial fix to the code" cycle.
>
> It seems to be part of Kent Beck's definition of TDD. AFAICT, he excuses
> it away as, "well, this bogus 'true' method will be fixed when we get to
> the refactor stage -- duplication between the 'true' in the code and the
> 'true' in the test," but I don't really buy that.
>
> Not all of the cases of cheating are going to be duplication -- say,
> you're supposed to be implementing the gamma function, but, starting off
> only testing natural numbers, you just implement fac first. AFAIK,
> implementing factorial is not going to help you implement gamma.
> Likewise, saying 'def size; 0 end' may make you feel better, but it's
> hardly progress towards an actual implementation of #size.

There's a point that Kent makes I'm not seeing in your description.
Hard coding the return value gets you right to a green bar, which is a
very important part of refactoring. As you refactor towards the real
implementation, the passing tests are an invariant that helps you to
know that you're not doing things that adversely affect not only the
method that you are working on, but everything else that you've
already written.

The value of this is difficult to see in the trivial examples we see
in books, but as an application grows it becomes increasingly
important.

> In any case, if the point is to keep the cycles short and to encourage
> the tests to be written, I'd at least like to inject a bit of
> pragmatism. We all get interrupted, have short memories, etc. -- at the
> very least, the stub implementation should be:
>    def empty?
>      true # XXX bogus code -- actual implementation pending tests
>    end

If that helps you to feel more confidence so that you can progress,
then do it. That's an important point of TDD. To provide YOU with
confidence that you're doing the right thing.

Cheers,
David

>
> (Remember, imaginary folks who are the audience of this rant: Bad code
> should *look* bad.)
>
> Fondly,
> Devin
>
>