win at wincent.com
Sat Sep 8 05:55:55 EDT 2007
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
> 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?
> 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:
> 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
> 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!
More information about the rspec-users