On 6/27/07, Rick DeNatale <rick.denatale / gmail.com> wrote:
> On 6/25/07, Giles Bowkett <gilesb / gmail.com> wrote:
>
> > Also keep in mind that is just a tutorial example. The goal is just to
> > communicate the process - spec first, make the spec pass, next step.
> > It's all about a single point of failure, and a clear mapping between
> > specs and functionality.
>
> Actually I believe that the pure process of
> test-driven/behavior-driven development is:
>
> 1) Write the test/spec
> 2) Ensure that it FAILS
> 3) Write the code to make it pass
> 4) Goto step 1
>
> Step 2 is to debug the spec.

The reason that we want to see the test fail is so that we can
confident that when it passes that it's passing because of the code we
wrote in step 3. Otherwise, we could write code that the test doesn't
interact with in any way resulting in a useless test and dead code.

Is that what you mean by "debug the spec?" If not, can you please explain?

Thx,
David

>
> --
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denhaven2.com/
>
>