[rspec-users] Preconditions

Ben Mabey ben at benmabey.com
Sat Sep 8 12:08:21 EDT 2007


David Chelimsky wrote:
> On 9/8/07, Pat Maddox <pergesu at gmail.com> wrote:
>   
>> 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!
>>>
>>> +1
>>>
>>> Cheers,
>>> Wincent
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> 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
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> 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


More information about the rspec-users mailing list