I’ve come across a couple of cases recently in which I was wishing it
was possible to parameterize shared specs. An example: I have defined
a number of rails resources, and it seems wasteful to have tens of
generated ‘xxx_controller_spec’ ‘xxx_controller_routing’ specs that
check the same mechanisms, but with different parameters (in this
case, the parameters would be the controller class name, and the path
the route should map to for instance). It doesn’t seem DRY, and it
adds a cognitive overhead of dealing with a large number of very
similar files in a project that essentially do the same thing.
Ideally, I’d have wanted to do something like this:
it_should_behave_like ‘a standard rails routed resource’, :controller
=> UserController, :path => ‘users’
I realise that the intention of the generated specs is to be evolved
as the underlying controllers do; however, for the routing or some
actions such as ‘destroy’, it’s unlikely there will be much variation
across controllers implementing the functionality, and it seems a
shame to have dozens of generated specs that look copy-and-pasted.
Hmm, after investigating a little more, this doesn’t sound feasible.
Instance variables are already shared between shared specs and their
callers, but I was thinking of the spec names themselves also being
parameterised, so that the following would be possible:
it “should map { :controller => ‘’, :action => ‘new’ } to
/admin//new” do
…
end
This would mean one of two things: class variables for and
, which wouldn’t work as these would be redefined by
successive specs as they get loaded; or some sort of templating or
preprocessing, which doesn’t sound like a good idea at all.
This would mean one of two things: class variables for and
, which wouldn’t work as these would be redefined by
successive specs as they get loaded; or some sort of templating or
preprocessing, which doesn’t sound like a good idea at all.
There is a strategy you can use for this. Define method in a helper
and use the included hook to extend the example group. To see a
working example of this, which actually may solve the exact problem
you’re trying to solve already, check out http://github.com/technoweenie/rspec_on_rails_on_crack.
There is a strategy you can use for this. Define method in a helper
and use the included hook to extend the example group. To see a
working example of this, which actually may solve the exact problem
you’re trying to solve already, check out http://github.com/technoweenie/rspec_on_rails_on_crack.
I had a look through the code for this and it looks like it does some
really cool stuff. But there isn’t one spec file to be found (a bit
unusual for an extension to a testing lib…), so I’d be more than a
little anxious using it in a real project.