RSpec Anti-Pattern - Don't Set @controller yourself
Posted by Rick DeNatale Wed, 26 Mar 2008 21:30:00 GMT
I was adding to an existing controller today at work and I was stumped because one of the examples in its controller spec was failing due to an exception thrown while rendering a view.
Normally RSpec controller tests, which are usually used to specify controller logic, bypass view rendering unless you specifically use the integrate_views method in the example group. The idea is that you should use view specs to specify the logic and output of views.
Since I was working in existing code, which pre-existed my being here, I’d followed some of the existing example groups in the file. These would typically look something like this:
describe HobbitController, "doing something" do
before(:each) do
@controller = HobbitController.new
#.. more setup stubbing etc.
end
#examples
endI finally realized that that first line in the before block was clobbering RSpecs ability to control whether or not views should be rendered. RSpec actually creates the controller instance variable for you, and extends it with a module which overrides the render method to allow integrate_views to control the rendering while allowing the expect_render expectation to work whether or not rendering actually happens.
So I’ve got a new task to clean up all the other controller specs.
