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:
- First, one uses the get, post, put,
delete or head method to simulate an HTTP request.
- 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[:person] won‘t work, but assigns["person"] 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["person"], but
again, assigns[:person] 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"
For cookies, you need to manually create the cookie, like this:
@request.cookies["key"] = CGI::Cookie.new("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')