Class | Spec::Rails::Example::ControllerExampleGroup |
In: |
vendor/plugins/rspec-rails/lib/spec/rails/example/controller_example_group.rb
|
Parent: | Spec::Rails::Example::FunctionalExampleGroup |
Controller Examples live in $RAILS_ROOT/spec/controllers/.
Controller Examples use Spec::Rails::Example::ControllerExampleGroup, which supports running specs for Controllers in two modes, which represent the tension between the more granular testing common in TDD and the more high level testing built into rails. BDD sits somewhere in between: we want to a balance between specs that are close enough to the code to enable quick fault isolation and far enough away from the code to enable refactoring with minimal changes to the existing specs.
No dependencies on views because none are ever rendered. The benefit of this mode is that can spec the controller completely independent of the view, allowing that responsibility to be handled later, or by somebody else. Combined w/ separate view specs, this also provides better fault isolation.
To run in this mode, include the integrate_views declaration in your controller context:
describe ThingController do integrate_views ...
In this mode, controller specs are run in the same way that rails functional tests run - one set of tests for both the controllers and the views. The benefit of this approach is that you get wider coverage from each spec. Experienced rails developers may find this an easier approach to begin with, however we encourage you to explore using the isolation mode and revel in its benefits.
Rspec on Rails will raise errors that occur in controller actions. In contrast, Rails will swallow errors that are raised in controller actions and return an error code in the header. If you wish to override Rspec and have Rail‘s default behaviour,tell the controller to use rails error handling …
before(:each) do controller.use_rails_error_handling! end
When using Rail‘s error handling, you can expect error codes in headers …
it "should return an error in the header" do response.should be_error end it "should return a 501" do response.response_code.should == 501 end it "should return a 501" do response.code.should == "501" end
controller | [R] | |
request | [R] | |
response | [R] |
You MUST provide a controller_name within the context of your controller specs:
describe "ThingController" do controller_name :thing ...
# File vendor/plugins/rspec-rails/lib/spec/rails/example/controller_example_group.rb, line 95 95: def controller_name(name) 96: @controller_class_name = "#{name}_controller".camelize 97: end
Use this to instruct RSpec to render views in your controller examples (Integration Mode).
describe ThingController do integrate_views ...
See Spec::Rails::Example::ControllerExampleGroup for more information about Integration and Isolation modes.
# File vendor/plugins/rspec-rails/lib/spec/rails/example/controller_example_group.rb, line 75 75: def integrate_views(integrate_views = true) 76: @integrate_views = integrate_views 77: end
Uses ActionController::Routing::Routes to parse an incoming path so the parameters it generates can be checked
params_from(:get, '/registrations/1;edit') => :controller => 'registrations', :action => 'edit', :id => 1
# File vendor/plugins/rspec-rails/lib/spec/rails/example/controller_example_group.rb, line 155 155: def params_from(method, path) 156: ensure_that_routes_are_loaded 157: ActionController::Routing::Routes.recognize_path(path, :method => method) 158: end
Uses ActionController::Routing::Routes to generate the correct route for a given set of options.
route_for(:controller => 'registrations', :action => 'edit', :id => 1) => '/registrations/1;edit'
# File vendor/plugins/rspec-rails/lib/spec/rails/example/controller_example_group.rb, line 145 145: def route_for(options) 146: ensure_that_routes_are_loaded 147: ActionController::Routing::Routes.generate(options) 148: end