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 => '<controller>', :action => 'new' } to
/admin/<path>/new" do
...
end
This would mean one of two things: class variables for <path> and
<controller>, 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
<[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
