[rspec-users] Preconditions

[Wincent Colaiuta]

El 8/9/2007, a las 2:15, Pat Maddox escribió:

> * Descriptions should be broken up based on the required fixture.  I
> don't split them up until I actually have to.  For example, if I'm
> writing a Stack class.  I'd probably start off with
>
> [snip]
>
> For a simple spec like this it's okay.  We could factor out the
> Stack.new call, and there's one other smell, but we'll get to that in
> a minute.
>
> Now what if we want to peek the stack?
>
> [snip]
>
> Now we've got clear duplication in three places:
>   (1) The constructor
>   (2) Call to add_item
>   (3) the 'it' specifier!
>
> It's clear that the fixture for "should not be empty" and "should let
> you peek" are the same.  They're also different from the "should be
> empty" so we split them up:
>
> [snip]
>
> There are two key benefits to that.  The first is that it's obvious
> where new specifications need to go.  The behavior for #pop whether a
> stack is empty or has an item is going to be different.  Also if you
> need some behavior that changes with 3 items, you can probably figure
> out that you should create a new description.
>
> An even bigger benefit is that it minimizes the brain processing
> required to figure out a spec.  If you create the fixture in the setup
> and don't vary it, it's trivial to scan through some simple
> expectations.
>
> This has to do with the smell that I alluded to earlier, which was the
> call to add_item.  Ideally your example will contain just one
> expectation and no other setup.  This reduces the concepts that change
> from example to example.  Change is where bugs pop up most of the
> time.  So if you're doing setup in an example, then you probably want
> to split it out from the current description.  In fact, in real life I
> would have split the descriptions up immediately after writing the
> "should not be empty" example.

Brilliantly written example, very clear!

+1

Cheers,
Wincent