On Tue, Dec 16, 2008 at 2:47 PM, Pat Maddox <perg...@gmail.com> wrote: > 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.
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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
