class ActionController::TestCase

assert_redirected_to page_url(title: ‘foo’)
If you’re using named routes, they can be easily tested using the original named routes’ methods straight in the test case.
== Testing named routes
cookies.clear
To clear the cookies for a test just clear the cookie collection:<br><br>cookies = “value”<br>session = “value”
To do this just assign a value to the session or cookie collection:
Sometimes you need to set up the session and cookie variables for a test.
== Manipulating session and cookie variables
action call which can then be asserted against.
For redirects within the same controller, you can even call follow_redirect and the redirect will be followed, triggering another
On top of the collections, you have the complete url that a given action redirected to available in redirect_to_url.
So assigns(:person) will work just like assigns["person"], but again, assigns[:person] will not work.
appease our yearning for symbols, though, an alternative accessor has been devised using a method call instead of index referencing.
For historic reasons, the assigns hash uses string-based keys. So assigns[:person] won’t work, but assigns["person"] will. To
assert flash.empty? # makes sure that there’s nothing in the flash
assert_equal “Dave”, cookies # makes sure that a cookie called :name was set as “Dave”
assert_not_nil assigns(:person) # makes sure that a @person instance variable was set
These collections can be used just like any other hash:
* cookies: Cookies being sent to the user on this request.
* flash: The flash objects currently in the session.
* session: Objects being saved in the session.
* assigns: Instance variables assigned in the action that are available for the view.
can be used against. These collections are:
In addition to these specific assertions, you also have easy access to various collections that the regular test/unit assertions
== Testing controller internals
end
tests WidgetController
class SpecialEdgeCaseWidgetsControllerTest < ActionController::TestCase
class name, you can explicitly set it with tests.
from the test class name. If the controller cannot be inferred from the test
ActionController::TestCase will automatically infer the controller under test
== Controller is automatically inferred
Test::Unit::TestCase and define @controller, @request, @response in setup.)
(Earlier versions of Rails required each functional test to subclass
may use this object to inspect the HTTP response in detail.
after calling post. If the various assert methods are not sufficient, then you
of the last HTTP response. In the above example, @response becomes valid
An ActionController::TestResponse object, representing the response
@response::
you might want to set some session properties before sending a GET request.
request. You can modify this object before sending the HTTP request. For example,
An ActionController::TestRequest, representing the current HTTP
@request::
The controller instance that will be tested.
@controller::
variables for use in the tests:
ActionController::TestCase will also automatically provide the following instance
== Special instance variables
end
post :create, json
json = {book: { title: “Love Hina” }}.to_json
def test_create
You can also send a real document in the simulated HTTP request.
end
end
assert_not_nil Book.find_by(title: “Love Hina”)
# Assert that the controller really put the book in the database.
assert_response :found
# the created book’s URI.
# Assert that the controller tried to redirect us to
post(:create, book: { title: “Love Hina” })
# Simulate a POST response with the given HTTP parameters.
def test_create
class BooksControllerTest < ActionController::TestCase
For example:
the controller’s HTTP response, the database contents, etc.
2. Then, one asserts whether the current state is as expected. “State” can be anything:
an HTTP request.
1. First, one uses the get, post, patch, put, delete or head method to simulate
Functional tests are written as follows:
== Basic example
different HTTP requests).
“stories” that can involve multiple controllers and multiple actions (i.e. multiple
integration tests (see ActionDispatch::IntegrationTest), which are more like
test a single controller action per test method. This should not be confused with
Superclass for ActionController functional tests. Functional tests allow you to