David Chelimsky wrote:
On Tue, Dec 16, 2008 at 2:01 PM, Lenny Marks <le...@aps.org> wrote:
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.
I posted on the blog, but essentially I don't think you guys are at
odds. Avdi is talking about examples named for methods:
it "#method_name" do
not example groups (which I think are fine, and I think Avdi does as well):
describe SomeObject do
describe "#method_name" do
context "some state" do
it "does something" do
Here there is a group named #method_name, but there are potentially
multiple examples of how that object responds to that message in
different states.
Actually, Avdi did argue against both cases... (Method names in example
groups and examples.)
Cheers,
David
-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"
..
<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._______________________________________________
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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
