class ActionController::TestCase - actionpack-4.2.4 Documentation

# class ActionController::TestCase

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 ActionDispatch::IntegrationTest), which are more like “stories” that can involve multiple controllers and multiple actions (i.e. multiple different HTTP requests).

## Basic example¶ ↑

Functional tests are written as follows:

1. First, one uses the `get`, `post`, `patch`, `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

You can also send a real document in the simulated HTTP request.

    def test_create
      json = {book: { title: "Love Hina" }}.to_json
      post :create, json
    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 explicitly 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 session and cookie variables¶ ↑

Sometimes you need to set up the session and cookie variables for a test. To do this just assign a value to the session or cookie collection:

    session[:key] = "value"
    cookies[:key] = "value"

To clear the cookies for a test just clear the cookie collection:

    cookies.clear

## 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.

    assert_redirected_to page_url(title: 'foo')