David
Thanks for the reply.
I think I wasn't clear with my original post: before blocks work fine,
this is just a readability/comprehension/maintenance concern.
We're using a describe (or context) block to name (or document) a
state, then using a separate before block to set up that state
(context). If that before block were to go astray the documentation
would cease to be correct.
It seems better to have this done in one place rather than two, as
separate description statements and setup code could lead to confusion
or errors through fragmented example groups.
I'm not sure how helpful it would be if the setup takes more than half
a line of code. Referencing a definition elsewhere wouldn't help
readability, though would still make it clear that the describe was
for that particular setup state.
Before blocks do have the same effect, and if positioned sensibly
should avoid these problems.
It's not a big deal, and the onus should probably be on the spec
author rather than the tools to produce clean and consistent specs?
I'm not surprised it's come up before, but I didn't find anything
searching the group.
Cheers
Nick
On Sep 20, 9:56 pm, David Chelimsky <dchelim...@gmail.com> wrote:
> On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf...@gmail.com> wrote:
> > I've been reading through the Rspec book to see if I missed any
> > tricks, and the discussion of before block use for context setup in
> > sec 12.6 struck me as interesting and something I had a knee-jerk
> > reaction to.
>
> > I think that when you are using nested examples to describe a context
> > change it is bad practice to allow any example within that group to
> > run outside of that context. This could happen simply because you
> > forgot to copy and paste (ouch) the setup code into your expectation.
>
> > before blocks solve this problem, but they are so tightly coupled to
> > the describe call in this case, why not make them a describe method
> > parameter? Ideally they would be the block passed to describe, but we
> > can't do that since the example group is using that already.
>
> > So I would propose something like this sketch:
>
> > describe "a new capacity 10 stack", :context => lambda {...@stack =
> > Stack.new(:capacity => 10)} do
> > describe "with 4 pushed ints", :context => lambda { 4.times { @stack
> > << rand(:int) } } do
> > it "should allow push and return the new size" do
> > �...@stack.push(rand(:int)).should == 5
> > end
> > end
> > end
>
> > And the :context would just be executed as if it were a before block.
>
> > Of course you can arrange your specs so that the before block is
> > directly after the describe, or similar, but this seems a nice
> > alternative to me.
>
> The order of the before blocks, relative to the examples, is
> irrelevant. An example group loads up all of its examples and before
> and after blocks before anything is run. In other words, these two
> will have the same effect:
>
> describe Thing do
> before(:each) { @thing = Thing.new }
> it "does something" do
> @thing.should do_something
> end
> end
>
> describe Thing do
> it "does something" do
> @thing.should do_something
> end
> before(:each) { @thing = Thing.new }
> end
>
> This is not the first time your idea has come up, and I've not
> included it before because I want to avoid assigning specific meaning
> to keys in the hash passed to describe(). rspec-2 will be using that
> hash as part of a plugin API, so the more I can leave available, the
> better. I'll be posting more about that soon, but first things first -
> gotta get the book off to the printer :)
>
> Cheers,
> David
>
>
>
> > It's a nubile idea though. Thoughts?
>
> _______________________________________________
> rspec-users mailing list
> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
