Class: ActionController::TestCase

Class | ActionController::TestCase
In: | lib/action_controller/test_case.rb
Parent: | ActiveSupport::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 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

### Methods

controller_class controller_class= determine_default_controller_class prepare_controller_class rescue_action_in_public! setup_controller_request_and_response tests

### Classes and Modules

Module ActionController::TestCase::RaiseActionExceptions

### Public Class methods

controller_class()
controller_class=(new_class)
determine_default_controller_class(name)
prepare_controller_class(new_class)
tests(controller_class)

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

### Public Instance methods

rescue_action_in_public!()

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

setup_controller_request_and_response()

[Validate]