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
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
