Lenny Marks <le...@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. > <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@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
