Class: ActionController::TestCase
- Inherits:
-
ActiveSupport::TestCase
- Object
- Minitest::Test
- ActiveSupport::TestCase
- ActionController::TestCase
- Includes:
- Behavior
- Defined in:
- actionpack/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.
Use integration style controller tests over functional style controller tests.
Rails discourages the use of functional tests in favor of integration tests (use ActionDispatch::IntegrationTest).
New Rails applications no longer generate functional style controller tests and they should only be used for backward compatibility. Integration style controller tests perform actual requests, whereas functional style controller tests merely simulate a request. Besides, integration tests are as fast as functional tests and provide lot of helpers such as as
, parsed_body
for effective testing of controller actions including even API endpoints.
Basic example
Functional tests are written as follows:
-
First, one uses the
get
,post
,patch
,put
,delete
orhead
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, params: { book: { title: "Love Hina" }})
# Asserts that the controller tried to redirect us to
# the created book's URI.
assert_response :found
# Asserts 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, body: 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 ActionDispatch::TestResponse object, representing the response of the last HTTP response. In the above example,
@response
becomes valid after callingpost
. If the various assert methods are not sufficient, then you may use this object to inspect the HTTP response in detail.
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:
-
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_equal "Dave", [:name] # makes sure that a cookie called :name was set as "Dave"
assert flash.empty? # makes sure that there's nothing in the flash
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"
[:key] = "value"
To clear the cookies for a test just clear the cookie collection:
.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')
Defined Under Namespace
Modules: Behavior
Constant Summary
Constants inherited from ActiveSupport::TestCase
ActiveSupport::TestCase::Assertion
Constants included from ActiveSupport::Testing::Assertions
ActiveSupport::Testing::Assertions::UNTRACKED
Instance Attribute Summary
Attributes included from Behavior
Method Summary
Methods included from Behavior
#build_response, #controller_class_name, #delete, #generated_path, #get, #head, #patch, #post, #process, #put, #query_parameter_names, #setup_controller_request_and_response
Methods included from ActiveSupport::Concern
#append_features, #class_methods, extended, #included
Methods included from ActionDispatch::TestProcess
#assigns, #cookies, #flash, #redirect_to_url, #session
Methods included from ActionDispatch::TestProcess::FixtureFile
Methods inherited from ActiveSupport::TestCase
parallelize, parallelize_setup, parallelize_teardown, test_order, test_order=
Methods included from ActiveSupport::Testing::Declarative
Methods included from ActiveSupport::Testing::FileFixtures
Methods included from ActiveSupport::Testing::TimeHelpers
#after_teardown, #freeze_time, #travel, #travel_back, #travel_to
Methods included from ActiveSupport::Testing::Deprecation
#assert_deprecated, #assert_not_deprecated, #collect_deprecations
Methods included from ActiveSupport::Testing::Assertions
#assert_changes, #assert_difference, #assert_no_changes, #assert_no_difference, #assert_not, #assert_nothing_raised