[rspec-users] New article on "Listening to Your Specs" up on Ruby Advent 2008
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:
>> 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.
>> I agree with most of the points in this article, but not so much the
>> part about:
>> 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.
>> 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.
>> 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.
> 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).
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users