Re: Listening to Your Specs

Lenny Marks — Fri, 19 Dec 2008 12:26:42 -0000

There was some followup discussion of this on the rspec-users mailing list.

I think there is some consensus that 'Contexts named after methods' is not a smell and can even be a natural result of 'Outside In' coding.

Re: Listening to Your Specs

Lenny Marks — Mon, 15 Dec 2008 15:38:37 -0000

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"
..

<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>

I don't agree much with the above either. I think this the difference between speccing behavior at the application level vs. object level. I don't feel its a smell to get down to the object level when necessary. One of the benefits of BDD at the object/code level(as opposed to feature level) is helping to flesh out the API(what classes, what methods, what inputs/outputs) that implements a feature. New classes and methods spring into existence as I realize that there are details(a new responsibility) that I eventually want to drill into but would only be distracting or messy at the current level. Using object level examples to focus in on something in isolation is a valuable technique. Again, its all about focussing at the right level of granularity.

For ex. part of an 'update profile' feature might involve showing a user an error message if he/she submits invalid data. Now I wouldn't start off thinking, I'm going to need a User class with a validate method, but going from the outside in might eventually drive me to it so that I can drill into all the details of what constitutes valid data directly/in isolation, without being mixed in with a bunch of other stuff or extra setup.

-lenny

Disqus - Latest Comments for lmarks

Re: Listening to Your Specs

Re: Listening to Your Specs