[rspec-users] alias method spec?

David Chelimsky dchelimsky at gmail.com
Wed Mar 21 08:59:27 EDT 2007

On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:
> "Bryan Helmkamp" <bhelmkamp at gmail.com> writes:
> > On 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >> On 3/20/07, Bryan Helmkamp <bhelmkamp at gmail.com> wrote:
> >> > I've experienced a similar situation before. The reason I looked at
> >> > testing that they are the same method is that it seemed more DRY to do
> >> > that than to copy/paste the specs for that method and replace the
> >> > name. WDYT?
> >>
> >> That makes sense. Another way to keep the code DRY would be to wrap
> >> the example in a loop:
> >>
> >> (pardon the trunk syntax....)
> >>
> >> describe Thing do
> >>   [:b, :c].each do |method|
> >>     it "should do a when you send it #{method}" do
> >>       #expect something....
> >>       Thing.new.send method
> >>     end
> >>   end
> >> end
> >>
> >> This way the same behaviour get specified for both methods, but
> >> there's only one set of specs describing the behaviour.
> >
> > I like that solution, David. I've used loops for defining specify
> > block in some other places, and I'm happy with the results. Just
> > wondering, if instead of having one Thing with two methods that are
> > identical, you instead had two types of things (Foo and Bar) with one
> > method that should behave the same for each, how would you go about
> > specifying that? Would you write a high level custom matcher? Use a
> > loop to create two context blocks? Or something else?
> We have this exact problem, and the solution I was kicking around was:
> Module Foo
>   def same; end
> end
> Module Bar
>   def same; end
> end
> context Foo, Bar, "Foo and Bar" do
>   setup do
>     same
>   end
> end
> where 'context' would accept a list of modules to include, and
> generate a new context for each.

That's a really interesting idea. If Foo and Bar have different
initializers, there needs to be a separate setup for each. The first
thing that comes to my mind is this:

describe Foo, Bar, "#some_method" do
  setup Foo do
    @obj = Foo.new(...)

  setup Bar do
    @obj = Bar.new(...)

  it "should do something" do

This could match up the module w/ the correct setup block and output this:

- should do something

- should do something

The thing I don't like about this is that if you have 10 classes that
implement one method, each in its own way, the output could start to
get quite verbose, with things like:

- should blah

- should other blah


Now we could solve that by storing all of the output and grouping it
together by Class, so you would still get:

- should blah
- should other blah

I can see this becoming a problem in terms of finding the code for a
given example. Perhaps we can have a CL switch that adds filenames
and/or line numbers to the output. Seems like this could spiral into a
lot of complexity. But it IS interesting.


>  -bob
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list