Modules will no longer be automatically included in RSpec version 1.1.4

Testing RSpec
1

Can anyone (David?) shed some light on what exactly this warning is
complaining about? I started seeing it when I upgraded to Rails 2.1
RC1 and the latest RSpec from git.

I’m getting it in some helper specs that I’m writing. And yes, I am
including a module there, to reuse some utility methods I originally
wrote for my controller tests (I’m switching to specs as fast as I
can, but I don’t have time to re-jigger all my tests over to specs yet).

Regards, Lori

2

It appears when you write a spec like

describe FooModule do …

Pat

3

RSpec currently includes the described module so that you can call
methods directly. It will no longerdo that automatically, so you’ll
have to manually include the module if you want these direct calls.

Rails helpers are defined in modules, so that’s why this is showing up.

Pat

4

So, for helper specs, one must now do something like:

describe SomeHelper do

include SomeHelper

before(:each) do
…
end

it “should do something”

end

That seems redundant, but I suppose there’s a good reason for it.

Thanks for the help, Pat!

Regards, Lori

5

On May 23, 2008, at 4:35 PM, Lori M Olson wrote:

Can anyone (David?) shed some light on what exactly this warning is
complaining about? I started seeing it when I upgraded to Rails 2.1
RC1 and the latest RSpec from git.

I’m getting it in some helper specs that I’m writing. And yes, I am
including a module there, to reuse some utility methods I originally
wrote for my controller tests (I’m switching to specs as fast as I
can, but I don’t have time to re-jigger all my tests over to specs
yet).

Helper example groups (in git) now have a helper object that you can
(and should) use. So instead of this:

describe SomeHelper do
it “should be helpful” do
some_helpful_method.should == “this result”
end
end

You do this:

describe SomeHelper do
it “should be helpful” do
helper.some_helpful_method.should == “this result”
end
end

That will make the warning go away.

The reason we did this is that somebody had a describe method in a
helper and it created a conflict :slight_smile: We realized then that including
the module implicitly was asking for trouble.

HTH,
David

6

On 23-May-08, at 6:23 PM, Pat M. wrote:

RSpec currently includes the described module so that you can call
methods directly. It will no longerdo that automatically, so you’ll
have to manually include the module if you want these direct calls.

Rails helpers are defined in modules, so that’s why this is showing
up.

So I find myself wondering - is this the case for just helper modules
or all modules? For instance, I have a module which gets included into
some controllers, but I’d like to spec against it directly so I don’t
have in those other controllers… I’m not sure how to set this up.
What’s the best practice?

I’m on Rails 2.0.2 and just updated to the fresh Rspec 1.1.4

thanks,
tim

7

On May 26, 2008, at 6:54 PM, Tim G. wrote:

modules or all modules? For instance, I have a module which gets
included into some controllers, but I’d like to spec against it
directly so I don’t have in those other controllers… I’m not sure
how to set this up. What’s the best practice?

First of all, don’t ever believe anybody when they tell you something
is a best practice.

That said - here’s what I usually do:

describe WhizBangModule do
it “should do something” do
whiz_banger = Object.new
whiz_banger.extend WhizBangModule
whiz_banger.whiz.should == “bang”
end
end

or something like that. Make sense?

8

On 23-May-08, at 4:48 PM, David C. wrote:

to specs yet).
You do this:
helper and it created a conflict :slight_smile: We realized then that including
the module implicitly was asking for trouble.

HTH,
David

rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

Thanks, David. That makes a lot more sense.

Regards, Lori

9

describe WhizBangModule do
it “should do something” do
whiz_banger = Object.new
whiz_banger.extend WhizBangModule
whiz_banger.whiz.should == “bang”
end
end

or something like that. Make sense?

Yes, that makes sense.

I like that as far as it goes, but I’m wondering if there’s a way to
take it one step further and actually have it extend the typical
controller functionality - some of my methods make use of the session,
or set some assigns, for instance. I’d love to be able to test it as
if it were in a controller already, with all the spec goodness that
comes along with that.

I can set up what you’ve done here to answer like a controller, but
that seems silly given that the same functionality is potentially
already available. I could also spec it in the context of one of the
controllers that includes it already, but that seems too specific.

thanks,
tim

10

On May 26, 2008, at 7:22 PM, Tim G. wrote:

but that seems silly given that the same functionality is
potentially already available. I could also spec it in the context
of one of the controllers that includes it already, but that seems
too specific.

class WhizBangController < ActionController::Base
include WhizBangModule
end

describe WhizBangController, “including WhizBangModule”, :type
=> :controller do
it “should do something” do
controller.whiz.should == “bang”
end
end

11

On 27 May 2008, at 01:22, Tim G. wrote:

whiz_banger = Object.new
whiz_banger.extend WhizBangModule
I like that as far as it goes, but I’m wondering if there’s a way to
take it one step further and actually have it extend the typical
controller functionality - some of my methods make use of the
session, or set some assigns, for instance. I’d love to be able to
test it as if it were in a controller already

I suspect that the conventional answer is to mock the pieces of
“typical controller functionality” you’re relying on, so that 1.
you’re speccing your module in isolation from any other code, instead
of trying to exercise two things at once, and 2. you’re explicitly
specifying (and exercising) the interface between your module and its
host class instead of making a whole bunch of invisible assumptions.

Cheers,
-Tom

12

On May 27, 2008, at 9:35 AM, Rick DeNatale wrote:

have in
describe WhizBangModule do
Yes, that makes sense.
with that.
end

It doesn’t seem to be mentioned in the changes list
http://rspec.info/changes.html

It’s there:

Deprecation warnings for specs that assume auto-inclusion of modules.

Just not highlighted. I’ll add something.

13

On Tue, May 27, 2008 at 8:46 AM, David C. [email protected]
wrote:

a best practice.

:controller do
it “should do something” do
controller.whiz.should == “bang”
end
end

Is this change something which should be highlighted for those who
don’t follow the mailing list?

It doesn’t seem to be mentioned in the changes list
http://rspec.info/changes.html

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/