How to Spec a Module to be used in a Controller

Testing RSpec
1

I want to be able to factor out bits of a controller’s behaviour into
modules, and spec them independently. E.g. modules like Authentication
and ExceptionHandling that are mixed into ApplicationController.

In my spec, I create a FakeController class which inherits from
ActionController::Base, and mix in the module.

This is working OK, but I’m struggling with the routing so that I can
use the integration session #get method to spin up my FakeController.
I have to set up the routing for this FakeController in a
before(:all), then reload the default routing in after(:all) so as not
to pollute the other specs.

Is this how other people do this? Is there a trick that I’m missing?

cheers,
Matt

2

On Thu, Oct 23, 2008 at 7:00 AM, Matt W. [email protected] wrote:

This is working OK, but I’m struggling with the routing so that I can use
the integration session #get method to spin up my FakeController.

Is that strictly necessary? Your fake controller’s never going to get
routed to in real life, so testing that isn’t important. Why not just
put things in the params[] array that matter to your module and call
the controller method directly? (I.e., don’t call “get :index” –
just call “index.”)

Another option would be to skip the fake controller, put the tests for
your module into a shared behavior spec, and include that shared
behavior in the spec for every controller that uses the module with
it_should_behave_like. You’d be testing the module’s behavior a few
times over, but you’d be doing it in the real controllers that really
use it.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

3

Matt W. [email protected] writes:

before(:all), then reload the default routing in after(:all) so as not
to pollute the other specs.

Is this how other people do this? Is there a trick that I’m missing?

Yeah, it’s kind of a bummer, just something you have to deal with cause
of Rails. What I do is set up a default route, you know the old-school
‘:controller/:action/:id’ kind.

Pat

4

On 23 Oct 2008, at 13:51, Stephen E. wrote:

the controller method directly? (I.e., don’t call “get :index” –
just call “index.”)

I guess not, but when I’m doing things that work with the
ActionController lifecycle, like listening for callbacks etc, I’d
prefer my specs to to depend too much on the interaction with
ActionController’s internals.

Another option would be to skip the fake controller, put the tests for
your module into a shared behavior spec, and include that shared
behavior in the spec for every controller that uses the module with
it_should_behave_like. You’d be testing the module’s behavior a few
times over, but you’d be doing it in the real controllers that really
use it.

Yeah, I have been doing this, but it’s starting to feel like a
headache to debug - the specs feel like they are a long way away from
the code. Do you know what I mean?

5

On 23 Oct 2008, at 14:49, Pat M. wrote:

Pat

Ok, so here’s my best attempt at this:

     # Briefly enables the old-fashioned wide-open routing for the

block, allowing you to run code that spins up a random controller
def with_basic_routing
ActionController::Routing::Routes.clear!
ActionController::Routing::Routes.draw do |map|
map.connect ‘:controller/:action’
end

       yield

       SK::Routing::DefaultRoutes.load_routes
     end

Any advance?