Sorry for the double post. Seems I haven't acquired the patience for
mailing lists yet :)
I had another idea which might scratch the itch, or might seem
horrible:
Take this example from some rails controller specs
describe SiteImagesController, request = "get :index" do
context "As a visitor:" do
before(:each) {stub_admin_check @controller, false}
should_not_execute :index, request
end
I was just looking at this and thought why not switch the string to
the context helper.
Something more like
context as_a_visitor do
should_not_execute :index, request
end
where as_a_visitor handles the stubbing and returns the documentation
string?
On Sep 21, 2:50 am, nruth <nick.rutherf...@gmail.com> wrote:
> 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-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
