pergesu at gmail.com
Sat Sep 8 11:18:16 EDT 2007
On 9/8/07, Wincent Colaiuta <win at wincent.com> wrote:
> 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!
> rspec-users mailing list
> rspec-users at rubyforge.org
To give credit where it's due, I'm pretty sure that's from my memory
of the early examples on rspec.rubyforge.org.
More information about the rspec-users