Class: ActionController::TestCase

Inherits:
ActiveSupport::TestCase
  • Object
show all
Includes:
Assertions, TestProcess
Defined in:
lib/action_controller/test_case.rb

Overview

Superclass for ActionController functional tests. Functional tests allow you to test a single controller action per test method. This should not be confused with integration tests (see ActionController::IntegrationTest), which are more like “stories” that can involve multiple controllers and mutliple actions (i.e. multiple different HTTP requests).

Basic example

Functional tests are written as follows:

  1. First, one uses the get, post, put, delete or head method to simulate an HTTP request.

  2. Then, one asserts whether the current state is as expected. “State” can be anything: the controller’s HTTP response, the database contents, etc.

For example:

class BooksControllerTest < ActionController::TestCase
  def test_create
    # Simulate a POST response with the given HTTP parameters.
    post(:create, :book => { :title => "Love Hina" })

    # Assert that the controller tried to redirect us to
    # the created book's URI.
    assert_response :found

    # Assert that the controller really put the book in the database.
    assert_not_nil Book.find_by_title("Love Hina")
  end
end

Special instance variables

ActionController::TestCase will also automatically provide the following instance variables for use in the tests:

@controller

The controller instance that will be tested.

@request

An ActionController::TestRequest, representing the current HTTP request. You can modify this object before sending the HTTP request. For example, you might want to set some session properties before sending a GET request.

@response

An ActionController::TestResponse object, representing the response of the last HTTP response. In the above example, @response becomes valid after calling post. If the various assert methods are not sufficient, then you may use this object to inspect the HTTP response in detail.

(Earlier versions of Rails required each functional test to subclass Test::Unit::TestCase and define @controller, @request, @response in setup.)

Controller is automatically inferred

ActionController::TestCase will automatically infer the controller under test from the test class name. If the controller cannot be inferred from the test class name, you can explicity set it with tests.

class SpecialEdgeCaseWidgetsControllerTest < ActionController::TestCase
  tests WidgetController
end

Testing controller internals

In addition to these specific assertions, you also have easy access to various collections that the regular test/unit assertions can be used against. These collections are:

  • assigns: Instance variables assigned in the action that are available for the view.

  • session: Objects being saved in the session.

  • flash: The flash objects currently in the session.

  • cookies: Cookies being sent to the user on this request.

These collections can be used just like any other hash:

assert_not_nil assigns(:person) # makes sure that a @person instance variable was set
assert_equal "Dave", cookies[:name] # makes sure that a cookie called :name was set as "Dave"
assert flash.empty? # makes sure that there's nothing in the flash

For historic reasons, the assigns hash uses string-based keys. So assigns won’t work, but assigns will. To appease our yearning for symbols, though, an alternative accessor has been devised using a method call instead of index referencing. So assigns(:person) will work just like assigns, but again, assigns will not work.

On top of the collections, you have the complete url that a given action redirected to available in redirect_to_url.

For redirects within the same controller, you can even call follow_redirect and the redirect will be followed, triggering another action call which can then be asserted against.

Manipulating the request collections

The collections described above link to the response, so you can test if what the actions were expected to do happened. But sometimes you also want to manipulate these collections in the incoming request. This is really only relevant for sessions and cookies, though. For sessions, you just do:

@request.session[:key] = "value"
@request.cookies["key"] = "value"

Testing named routes

If you’re using named routes, they can be easily tested using the original named routes’ methods straight in the test case. Example:

assert_redirected_to page_url(:title => 'foo')

Defined Under Namespace

Modules: Assertions, RaiseActionExceptions

Constant Summary collapse

@@controller_class = 
nil

Class Method Summary collapse

Instance Method Summary collapse

Methods included from Assertions

#clean_backtrace

Methods included from TestProcess

#assigns, #build_request_uri, #cookies, #delete, #find_all_tag, #find_tag, #fixture_file_upload, #flash, #get, #head, #html_document, included, #method_missing, #post, #process, #put, #redirect_to_url, #session, #with_routing, #xml_http_request

Constructor Details

#initialize(*args) ⇒ TestCase

Returns a new instance of TestCase.



108
109
110
111
 
# File 'lib/action_controller/test_case.rb', line 108

def initialize(*args)
  super
  @controller = nil
end

Dynamic Method Handling

This class handles dynamic methods through the method_missing method in the class ActionController::TestProcess

Class Method Details

.controller_class ⇒ Object 



170
171
172
173
174
175
176
 
# File 'lib/action_controller/test_case.rb', line 170

def controller_class
  if current_controller_class = read_inheritable_attribute(:controller_class)
    current_controller_class
  else
    self.controller_class = determine_default_controller_class(name)
  end
end

.controller_class=(new_class) ⇒ Object 



165
166
167
168
 
# File 'lib/action_controller/test_case.rb', line 165

def controller_class=(new_class)
  prepare_controller_class(new_class) if new_class
  write_inheritable_attribute(:controller_class, new_class)
end

.determine_default_controller_class(name) ⇒ Object 



178
179
180
181
182
 
# File 'lib/action_controller/test_case.rb', line 178

def determine_default_controller_class(name)
  name.sub(/Test$/, '').constantize
rescue NameError
  nil
end

.prepare_controller_class(new_class) ⇒ Object 



184
185
186
 
# File 'lib/action_controller/test_case.rb', line 184

def prepare_controller_class(new_class)
  new_class.send :include, RaiseActionExceptions
end

.tests(controller_class) ⇒ Object

Sets the controller class name. Useful if the name can’t be inferred from test class. Expects controller_class as a constant. Example: tests WidgetController.



161
162
163
 
# File 'lib/action_controller/test_case.rb', line 161

def tests(controller_class)
  self.controller_class = controller_class
end

Instance Method Details

#rescue_action_in_public! ⇒ Object

Cause the action to be rescued according to the regular rules for rescue_action when the visitor is not local



205
206
207
 
# File 'lib/action_controller/test_case.rb', line 205

def rescue_action_in_public!
  @request.remote_addr = '208.77.188.166' # example.com
end

#setup_controller_request_and_response ⇒ Object 



189
190
191
192
193
194
195
196
197
198
199
200
201
202
 
# File 'lib/action_controller/test_case.rb', line 189

def setup_controller_request_and_response
  @request = TestRequest.new
  @response = TestResponse.new

  if klass = self.class.controller_class
    @controller ||= klass.new rescue nil
  end

  if @controller
    @controller.request = @request
    @controller.params = {}
    @controller.send(:initialize_current_url)
  end
end