On 1/19/07, M. Edward (Ed) Borasky <znmeb / cesmail.net> 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.

First of all, it's just a simple example for people brand new to
RSpec.  It's good to take baby steps.  As you do it more you'll
obviously combine a couple steps into one.  But if you get stuck you
can always take a few steps back and then do the baby steps.

Now for the more important theoretical point...

There are two key parts when doing TDD/BDD.  The first is writing a
spec that fails.  The second is getting it passing.  I do that every
single time, no matter how trivial the code is. After you've been
doing BDD for a while you'll probably write a spec and then write the
code, run the spec, and move on.  That'll work really well for you for
a long time.  Then one day you're going to do that and your spec will
pass, but some part of the behavior still doesn't seem right.  You
spend a lot of time hunting this bug down, and finally you get
frustrated and tear out the new code to start from square one.  And
you run your spec...and it's green.  What the hell?  You just yanked
out your code.  Then you realize that you wrote the wrong spec, and
vow never to skip that trivial red step again.

Pat