[rspec-devel] [ rspec-Feature Requests-10718 ] Add :locals hash to 'it_should_behave_like' method (SharedBehavior)

noreply at rubyforge.org noreply at rubyforge.org
Wed May 9 11:19:43 EDT 2007

Feature Requests item #10718, was opened at 2007-05-09 10:36
You can respond by visiting: 

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: Add :locals hash to 'it_should_behave_like' method (SharedBehavior)

Initial Comment:
It would be great if we could pass arbitrary variables into the shared behavior specs, for things such as differing controller actions.  Right now, I'm having to do the following:

before(:all) do
   @action = "foo"
it_should_behave_like "CRUD"

Instead, I could imagine something like the following, a la partial locals:

it_should_behave_like "CRUD", :locals => { :action => "foo" }


>Comment By: Chris Hoffman (hoffman_c)
Date: 2007-05-09 11:19

how would @thing be assigned in the call to
it_should_behave_like in your example?  

I was imagining that a local 'thing' variable would get
assigned, perhaps with block locals.


Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-09 11:10

Interesting idea but there's a disconnect. Locals are actually slung over to another scope (the partial), whereas shared examples are all executed in the same scope as any non-shared examples. It's, conceptually, a different animal, that will surely lead to confusion when you start doing this:

describe Thing do
  before(:each) do
    @thing = Thing.new(:some_state)
  it_should_behave_like "other things", :locals => { :thing => Thing.new(:some_other_state) }
  it "should do something unique" do
    @thing.should write_novels

In this case, both assignments to @thing happen in the same context, so the last one executed wins. I, personally, would rather not have to debug that scenario.

Other thoughts?


You can respond by visiting: 

More information about the rspec-devel mailing list