[rspec-users] New article on "Listening to Your Specs" up on Ruby Advent 2008
pergesu at gmail.com
Tue Dec 16 15:47:41 EST 2008
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.
> 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).
More information about the rspec-users