rspec users - May 2008 - Modules will no longer be automatically included in RSpec version 1.1.4

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

It appears when you write a spec like

describe FooModule do ...

Pat


On 5/23/08, Lori M Olson <loriolson at mac.com>
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).
>
> Regards, Lori
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

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
On 5/23/08, Pat Maddox <pergesu at gmail.com>
wrote:
> It appears when you write a spec like
>
> describe FooModule do ...
>
> Pat
>
>
> On 5/23/08, Lori M Olson <loriolson at mac.com> 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).
>>
>> Regards, Lori
>>
>>
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>

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 :) We realized then that including  
the module implicitly was asking for trouble.

HTH,
David

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

On 23-May-08, at 4:23 PM, Pat Maddox 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.
>
> Pat
> On 5/23/08, Pat Maddox <pergesu at gmail.com> wrote:
>> It appears when you write a spec like
>>
>> describe FooModule do ...
>>
>> Pat
>>
>>
>> On 5/23/08, Lori M Olson <loriolson at mac.com> 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).
>>>
>>> Regards, Lori
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

On 23-May-08, at 4:48 PM, David Chelimsky wrote:
> 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 :) We realized then that including  
> the module implicitly was asking for trouble.
>
> HTH,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Thanks, David.  That makes a lot more sense.

Regards, Lori

On 23-May-08, at 6:23 PM, Pat Maddox 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

On May 26, 2008, at 6:54 PM, Tim Glen wrote:
> On 23-May-08, at 6:23 PM, Pat Maddox 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?
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?


>
>
> I''m on Rails 2.0.2 and just updated to the fresh Rspec 1.1.4
>
> thanks,
> tim
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

>> 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?
>
> 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?

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

On 27 May 2008, at 01:22, Tim Glen 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

On May 26, 2008, at 7:22 PM, Tim Glen wrote:
>>> 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?
>>
>> 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?
>
>
> 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.
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

On Tue, May 27, 2008 at 8:46 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:
>
> On May 26, 2008, at 7:22 PM, Tim Glen wrote:
>
>>>> 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?
>>>
>>> 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?
>>
>>
>> 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.
>
> 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
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/

On May 27, 2008, at 9:35 AM, Rick DeNatale wrote:
> On Tue, May 27, 2008 at 8:46 AM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
>>
>> On May 26, 2008, at 7:22 PM, Tim Glen wrote:
>>
>>>>> 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?
>>>>
>>>> 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?
>>>
>>>
>>> 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.
>>
>> 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
>
> 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
It''s there:

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

Just not highlighted. I''ll add something.
>
>
> -- 
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denhaven2.com/
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users