Parameterized shared specs: good or bad idea?

Hi,

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.

Any thoughts?

Thanks,
Nick

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.

Ah well -

Cheers,
Nick

On Sat, Mar 29, 2008 at 6:36 PM, Nick C

On Sat, Mar 29, 2008 at 3:03 PM, Nick C
[email protected] wrote:

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.

Cheers,
David

On 29 Mar 2008, at 21:41, David C. wrote:

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.

Ashley

Thanks David, that looks like exactly what I was looking for - I’m
just sorry I didn’t think of it myself!

Cheers,
Nick

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs