David Chelimsky wrote: > 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 >
What was the motivation behind taking that tutorial down, BTW? I really like and benefited from it when I was starting to learn rspec. Was it just a maintenance issue as far as updating the tutorial to the current API (DSL)? -Ben _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
