On 9/8/07, Pat Maddox <[EMAIL PROTECTED]> wrote: > On 9/8/07, Wincent Colaiuta <[EMAIL PROTECTED]> 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! > > > > +1 > > > > Cheers, > > Wincent > > > > _______________________________________________ > > rspec-users mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > To give credit where it's due, I'm pretty sure that's from my memory > of the early examples on rspec.rubyforge.org.
Thanks for that Pat. We pulled that tutorial down a while ago but you can get the textile source for it like so: svn export svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0/doc/src/tutorials Cheers, David > > Pat > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
