The new rspec beta book and the rspec site mentions that it is
possible to add a hash to “describe” and “it” constructs but very,
very litle information about the particulars.
What can the options hash be used for and what should it be used for?
F.x. I have some identical examples that I need to run against a wide
range of different models that have two configuration parameters that
sometimes differ. I am thus thinking of using the has like this in
example groups (tptions which are recoginzed in helpers, macros etc):
describe XXXX-MODEL, :fixturesRelativeRootDir =>
‘testfixtures’, :serviceDescriptorRelativePath => ‘services/
RubyHelloExample.service’
Does usage of custom options like this make sense rspec-wise ?
Finally, I did find out myself that I can get the hash from a helper’s
Spec::Runner.configure.config.before(:all) using “self.class”.
However, this does not work inside nested “it” constructs. Any advice ?
mortench wrote:
The new rspec beta book and the rspec site mentions that it is
possible to add a hash to “describe” and “it” constructs but very,
very litle information about the particulars.
What can the options hash be used for and what should it be used for?
This might be used for tagging examples, marking examples for use with
formatters, or other purposes probably not bearing on spec execution.
I’m not saying they could or couldn’t be used the way you’re suggesting,
but there are other possibilities you should try first IMO.
F.x. I have some identical examples that I need to run against a wide
range of different models that have two configuration parameters that
sometimes differ. I am thus thinking of using the has like this in
example groups (tptions which are recoginzed in helpers, macros etc):
I have used a callback for this, but I understand that rspec 1.2 has
macros that can take args the way your shared example can’t. I haven’t
dug into them.
Here’s the callback approach demonstrated.
describe “shared”, :shared => true
it “…” do
options = shared_options()
…
end
end
describe “thingy”
it_should_behave_like “shared”
def shared_options
{ :foo => ‘bar’, :baz => 'buz }
end
end
Randy
On Tue, May 12, 2009 at 12:14 PM, mortench [email protected] wrote:
describe XXXX-MODEL, :fixturesRelativeRootDir =>
‘testfixtures’, :serviceDescriptorRelativePath => ‘services/
RubyHelloExample.service’
Does usage of custom options like this make sense rspec-wise ?
Finally, I did find out myself that I can get the hash from a helper’s
Spec::Runner.configure.config.before(:all) using “self.class”.
However, this does not work inside nested “it” constructs. Any advice ?
You can access the group and example options from within an example:
describe “group options hash”, :defined_in => :group do
it “is available in examples via self.class.options” do
self.class.options[:defined_in].should == :group
end
end
describe “example options hash” do
it “is available in examples directly”, :defined_in => :example do
options[:defined_in].should == :example
end
end
HTH,
David
On 13 Maj, 07:28, David C. [email protected] wrote:
You can access the group and example options from within an example:
describe “group options hash”, :defined_in => :group do
it “is available in examples via self.class.options” do
self.class.options[:defined_in].should == :group
end
end
Yes, I got this to work too but not for nested describes as below:
describe “group options hash”, :defined_in => :group do
…
describe “nested describe wont work”
it “is available in examples via self.class.options” do
self.class.options[:defined_in].should == :group # WONT work
end
end
end
BTW. I am actually accessing the hash from within a common helper
files in a before action setup by Spec::Runner.configure. Hence it is
important that accessing the Hash work regardless of how the describes
are nested.
On Wed, May 13, 2009 at 3:36 PM, mortench [email protected] wrote:
BTW. I am actually accessing the hash from within a common helper
files in a before action setup by Spec::Runner.configure. Hence it is
important that accessing the Hash work regardless of how the describes
are nested.
Just catching up on some old mail here - would you please add a
feature request for this? http://rspec.lighthouseapp.com
On 13 Maj, 01:14, Randy H. [email protected] wrote:
mortench wrote:
The new rspec beta book and the rspec site mentions that it is
possible to add a hash to “describe” and “it” constructs but very,
very litle information about the particulars.
What can the options hash be used for and what should it be used for?
This might be used for tagging examples, marking examples for use with
formatters, or other purposes probably not bearing on spec execution.
“not bearing on spec execution”. I.e. for meta-data only. Any official
word on thos?
I’m not saying they could or couldn’t be used the way you’re suggesting,
but there are other possibilities you should try first IMO.
Ok. Thanks for the advice.
I have used a callback for this, but I understand that rspec 1.2 has
macros that can take args the way your shared example can’t. I haven’t
dug into them.
Ok. will look into that.
it_should_behave_like “shared”
def shared_options
{ :foo => ‘bar’, :baz => 'buz }
end
end
Thanks for the suggestion. I can see how it world work, but for this
particular problem I have (where 3parties would need to reuse my
tests), I would like something that not only works but is also simple
and elegant…
And the above is a bit verbose I think compared to just
describe “thingy”, :foo => ‘bar’, :baz => 'buz
…
end