Merge branch 'master' of git@github.com:rails/rails

1 files changed, 62 insertions, 1 deletions

diff --git a/actionpack/lib/action_controller/test_case.rb b/actionpack/lib/action_controller/test_case.rb
index 77c6f26eac..3e66947d5f 100644
--- a/actionpack/lib/action_controller/test_case.rb
+++ b/actionpack/lib/action_controller/test_case.rb
@@ -15,6 +15,65 @@ module ActionController
     end
   end
 
+  # 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:
+  #
+  # <b>@controller</b>::
+  #      The controller instance that will be tested.
+  # <b>@request</b>::
+  #      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.
+  # <b>@response</b>::
+  #      An ActionController::TestResponse object, representing the response
+  #      of the last HTTP response. In the above example, <tt>@response</tt> 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
   class TestCase < ActiveSupport::TestCase
     # When the request.remote_addr remains the default for testing, which is 0.0.0.0, the exception is simply raised inline
     # (bystepping the regular exception handling from rescue_action). If the request.remote_addr is anything else, the regular
@@ -41,6 +100,8 @@ module ActionController
     @@controller_class = nil
 
     class << self
+      # Sets the controller class name. Useful if the name can't be inferred from test class.
+      # Expects +controller_class+ as a constant. Example: <tt>tests WidgetController</tt>.
       def tests(controller_class)
         self.controller_class = controller_class
       end
@@ -80,4 +141,4 @@ module ActionController
       @request.remote_addr = '208.77.188.166' # example.com
     end
  end
-end
\ No newline at end of file
+end