On Sat, Mar 29, 2008 at 3:03 PM, Nick C
<[EMAIL PROTECTED]> wrote:
> 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.
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
>
> 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
>
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
