My last reply seems to have been swallowed by the Ajax monster.
In brief, my suggestion is just for readability/maintenance. I feel
the describe/context and before blocks are the same thing put in two
places, one being documentation and the other implementation.
Splitting them up like this seems like asking for trouble.
That said, before blocks do achieve the same result, albeit somewhat
inside out, and if put just after the describe it's clear what is
going on.
It's fair enough (particularly at this stage of development) to say
that the onus should be on the spec author rather than the tools to
write legible specs.
Thanks for the reply
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
