[rspec-users] New article on "Listening to Your Specs" up on Ruby Advent 2008

David Chelimsky dchelimsky at gmail.com
Tue Dec 16 15:49:49 EST 2008

On Tue, Dec 16, 2008 at 2:47 PM, Pat Maddox <pergesu at gmail.com> wrote:
> Lenny Marks <lenny at aps.org> writes:
>> On Dec 9, 2008, at 10:40 PM, Avdi Grimm wrote:
>>> I contributed an article on BDD and RSpec to the Ruby Advent Calendar
>>> 2008, going over some of the rules I've collected for interpreting
>>> what your specs say about your design.  It can be found here:
>>> http://advent2008.hackruby.com/past/2008/12/10/
>>> listening_to_your_specs/
>>> --
>>> Avdi
>> I'm curious where others stand on the topic of object level specs
>> with describe blocks named after methods.  I posted the comment below
>> with my 2 cents.
>> -lenny
>> I agree with most of the points in this article, but not so much the
>> part about:
>> <quote>
>> Contexts named after methods
>> A describe block should encapsulate a particular scenario: an object
>> or set of objects in a specific configuration. If objects are nouns,
>> and methods are verbs, then contexts should describe nouns, not verbs.
>> </quote>
>> I think this is more or less what Aslak was saying but I wanted to
>> get more specific. IMO, using rspec to spec behavior at the object/
>> unit level, it often makes perfect sense to describe the behavior of
>> the verbs(methods). I think the following contrived example would be
>> fine. It clearly shows me the what this method does and what the
>> scenarios it handles are.
>> describe Account, "#debit" #maybe 'debiting' is better, but #debit is
>> actually more descriptive of the API which is the level I'm at here.
>> describe "with sufficient funds"
>> it "should reduce balance by debited amount"
>> it "should ..."
>> describe "with insufficient funds"
>> it "should raise an InsufficentFundsError"
>> it "should ...
>> Actually in the above example I probably would have started with the
>> following and only grouped into nested contexts when I started
>> repeating myself(e.g. repetition of 'when balance is sufficient')
>> describe Account, "#debit"
>> it "should reduce balance by debited amount when balance is sufficient"
>> it "should raise an InsufficentFundsError when insufficient"
>> ..
> Yes.  This style of specification has a lot of documentation value.  You
> look at the RDoc for a method that looks like what you want, and then
> you can look at the spec to get concrete examples of how it's used.
> A friend of mine has toyed with the idea of putting the specs directly
> in the RDoc, or generating RDoc from the specs.  Seems promising.

I want to hear more about this. It's something that I've been toying
with in my head, not so much in code.

>> <quote>
>> Examples named after methods
>> There is rarely a one-to-one relationship between desired behaviors
>> and methods on an object. When you name an example after the method
>> it tests, it's a clue that you have started to think in
>> "implementation brain" rather than "behavior brain". You're thinking
>> "I know we are going to need a method "#foo" which does such-and-so,
>> so I'll just start spec-ing it now…". Step back, and think about the
>> behavior you are really interested in. You may find it changes how
>> you write examples. Or, you may find that you didn't need that method
>> at all.
>> </quote>
> And when you do know that you need the method?  Like if you had driven
> it from working outside-in.
> I don't like a lot of the stuff that Avdi writes.  He made some pretty
> good points in this article though, but I would hope that nobody holds
> it up as a canonical description of BDD (I don't think there really
> is/should be one, but if there were, it'd have to be Dan's stuff imo).
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list