Fixed wording in Assertion docs, changed ‘Assert’ -> ‘Asserts’

actionmailer/lib/action_mailer/test_helper.rb

@@ -40,7 +40,7 @@ module ActionMailer
       end
     end
 
-    # Assert that no emails have been sent.
+    # Asserts that no emails have been sent.
     #
     #   def test_emails
     #     assert_no_emails

actionpack/lib/action_dispatch/testing/assertions/response.rb

@@ -42,7 +42,7 @@ module ActionDispatch
         end
       end
 
-      # Assert that the redirection options passed in match those of the redirect called in the latest action.
+      # Asserts that the redirection options passed in match those of the redirect called in the latest action.
       # This match can be partial, such that <tt>assert_redirected_to(controller: "weblog")</tt> will also
       # match the redirection of <tt>redirect_to(controller: "weblog", action: "show")</tt> and so on.
       #

activesupport/lib/active_support/testing/assertions.rb

@@ -3,7 +3,7 @@ require 'active_support/core_ext/object/blank'
 module ActiveSupport
   module Testing
     module Assertions
-      # Assert that an expression is not truthy. Passes if <tt>object</tt> is
+      # Asserts that an expression is not truthy. Passes if <tt>object</tt> is
       # +nil+ or +false+. "Truthy" means "considered true in a conditional"
       # like <tt>if foo</tt>.
       #

guides/source/testing.md

@@ -319,7 +319,7 @@ Rails adds some custom assertions of its own to the `minitest` framework:
 | `assert_recognizes(expected_options, path, extras={}, message=nil)`               | Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.|
 | `assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)` | Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.|
 | `assert_response(type, message = nil)`                                            | Asserts that the response comes with a specific status code. You can specify `:success` to indicate 200-299, `:redirect` to indicate 300-399, `:missing` to indicate 404, or `:error` to match the 500-599 range. You can also pass an explicit status number or its symbolic equivalent. For more information, see [full list of status codes](http://rubydoc.info/github/rack/rack/master/Rack/Utils#HTTP_STATUS_CODES-constant) and how their [mapping](http://rubydoc.info/github/rack/rack/master/Rack/Utils#SYMBOL_TO_STATUS_CODE-constant) works.|
-| `assert_redirected_to(options = {}, message=nil)`                                 | Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such that `assert_redirected_to(controller: "weblog")` will also match the redirection of `redirect_to(controller: "weblog", action: "show")` and so on. You can also pass named routes such as `assert_redirected_to root_path` and Active Record objects such as `assert_redirected_to @article`.|
+| `assert_redirected_to(options = {}, message=nil)`                                 | Asserts that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such that `assert_redirected_to(controller: "weblog")` will also match the redirection of `redirect_to(controller: "weblog", action: "show")` and so on. You can also pass named routes such as `assert_redirected_to root_path` and Active Record objects such as `assert_redirected_to @article`.|
 
 You'll see the usage of some of these assertions in the next chapter.