rspec users - Mar 2008 - 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 => ''<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
<nick.curry+rspec-users at gmail.com> 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
>

On Sat, Mar 29, 2008 at 3:03 PM, Nick C
<nick.curry+rspec-users at gmail.com> 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
>  <nick.curry+rspec-users at gmail.com> 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
>  rspec-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-users
>

On 29 Mar 2008, at 21:41, David Chelimsky 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20080330/e3a9b767/attachment.html

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

Cheers,
Nick

On Sat, Mar 29, 2008 at 10:41 PM, David Chelimsky <dchelimsky at
gmail.com> wrote:
> On Sat, Mar 29, 2008 at 3:03 PM, Nick C
>
> <nick.curry+rspec-users at gmail.com> 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
>  >  <nick.curry+rspec-users at gmail.com> 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
>  >  rspec-users at rubyforge.org
>  >  http://rubyforge.org/mailman/listinfo/rspec-users
>  >
>  _______________________________________________
>  rspec-users mailing list
>  rspec-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-users
>