[rspec-users] [Rails] Controller testing problem

[Zach Moazeni]

Bleh,

I forgot to mention, if you have to maintain controller action code  
that is dependent on instance variables set elsewhere, here is a ruby  
hack that will allow you to setup the context. (Please note, I  
recommend refactoring the code under test but I understand sometimes  
the preconditions of a test need to be a little....slimy. However,  
both the code and the spec are smelly)

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')
require File.expand_path(File.dirname(__FILE__) + '/../spec_helpers/ 
controller_behaviors')

describe SomeController do
   stub_all_filters!

   describe "#foo" do
     def do_get
       get :foo
     end

     it "should do something" do
       controller.send(:instance_variable_set, "@bar", "here's bar")
       do_get
     end
   end
end

class SomeController < ApplicationController
   def foo
     p "need to do something with #{@bar}"
   end
end

Here's a gist in case the code formatting goes awry http://gist.github.com/142050 
  .

On Jul 7, 2009, at 8:29 AM, Zach Moazeni wrote:

> Hey Ignacy,
>
> I think I'm in the minority on this one, but I tend to keep my  
> action logic independent of filters. Doing that, my typical  
> controller spec begins like this:
>
> require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')
> require File.expand_path(File.dirname(__FILE__) + '/../spec_helpers/ 
> controller_behaviors')
>
> describe SomeController do
>  stub_all_filters!
>
>  describe ...
>
>  ...
> end
>
> The method "stub_all_filters!" is a custom rolled, per project  
> maintained, rspec hack that rips through Rails's internal methods to  
> find the filters on a controller and creates a "before do ... end"  
> that stubs each filter to "true" [1]
>
> I still use before filters because it's a good fit for many plugins  
> such as ssl_requirement and authentication. However 1) I don't  
> explicitly split up controller action behavior into filters and 2)  
> the controller actions can depend on the filters indirectly by  
> consuming methods like "self.current_user"
>
> I know you're maintaining prior-written code, but I thought this  
> would be relevant. I hope this helps more than it confuses.
>
> [1] - http://gist.github.com/142047

--
Zach Moazeni
http://simplechatter.com