[rspec-users] alias method spec?

Bob Cotton bob.cotton at rallydev.com
Wed Mar 21 10:50:04 EDT 2007


"David Chelimsky" <dchelimsky at gmail.com> writes:
> On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:
>> "Bryan Helmkamp" <bhelmkamp at gmail.com> writes:
>> > 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(...)
>   end
>
>   setup Bar do
>     @obj = Bar.new(...)
>   end
>
>   it "should do something" do
>     ...
>   end
> end
>
> This could match up the module w/ the correct setup block and output this:
>
> Foo#some_method
> - should do something
>
> Bar#some_method
> - 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:
>
> Foo#a
> - should blah
>
> Foo#b
> - should other blah
>
> etc
>
> Now we could solve that by storing all of the output and grouping it
> together by Class, so you would still get:
>
> Foo#a
> - 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.
>
> Thoughts?

  [ I'm still thinking in context/specify. ]

David, your suggestion does answer Bryan's scenario, 

  "you instead had two types of things (Foo and Bar) with one method
  that should behave the same for each"

It is an interesting approach to testing a common behavior between two
classes. But what about factoring the specify into a module:

module Common
  specify "..."
end

then include that into the context?

I guess I should have been more specific in my example. 

My take on it was having modules that contained some helper methods,
with the same name, that would be shared across contexts.

We are using rspec mostly for defining acceptance tests. We have
a system that has multiple "editions", where the behavior of the
editions is largely the same. Let's call these editions Large and
Small. 

I would like to write a context that defines the common behavior of
all editions, but have setup create the correct edition, for example:

module Large
  def create; end
end

module Small
  def create; end
end

context Large, Small, "All editions" do
  setup do
    @system = create
  end
  specify ...
end

It's kind of a dependency injection for contexts.


- Bob


More information about the rspec-users mailing list