@@ -638,9 +638,9 @@ We were able to successfully test a very small workflow for visiting our blog an
Functional Tests for Your Controllers
-------------------------------------
In Rails, testing the various actions of a controller is a form of writing functional tests. Remember your controllers handle the incoming web requests to your application and eventually respond with a rendered view. When writing functional tests, you're testing how your actions handle the requests and the expected result, or response in some cases an HTML view.
In Rails, testing the various actions of a controller is a form of writing functional tests. Remember your controllers handle the incoming web requests to your application and eventually respond with a rendered view. When writing functional tests, you are testing how your actions handle the requests and the expected result or response, in some cases an HTML view.
### What to Include in your Functional Tests
### What to include in your Functional Tests
You should test for things such as:
...
...
@@ -650,8 +650,7 @@ You should test for things such as:
* was the correct object stored in the response template?
* was the appropriate message displayed to the user in the view?
The easiest way to see functional tests in action is to generate a controller
scaffold:
The easiest way to see functional tests in action is to generate a controller using the scaffold generator:
# Reload association to fetch updated data and assert that title is updated.
article.reload
assert_equal"updated",article.title
end
```
Notice we're starting to see some duplication in these three tests, they both access the same Article fixture data. We can D.R.Y. this up by using the `setup` and `teardown` methods provided by `ActiveSupport::Callbacks`.
Our test should now look something like this, disregard the other tests we're leaving them out for brevity.
Our test should now look something as what follows. Disregard the other tests for now, we're leaving them out for brevity.
```ruby
require'test_helper'
...
...
@@ -952,8 +956,12 @@ class ArticlesControllerTest < ActionDispatch::IntegrationTest
@@ -1123,7 +1132,7 @@ In order to test that your mailer is working as expected, you can use unit tests
For the purposes of unit testing a mailer, fixtures are used to provide an example of how the output _should_ look. Because these are example emails, and not Active Record data like the other fixtures, they are kept in their own subdirectory apart from the other fixtures. The name of the directory within `test/fixtures` directly corresponds to the name of the mailer. So, for a mailer named `UserMailer`, the fixtures should reside in `test/fixtures/user_mailer` directory.
When you generated your mailer, the generator creates stub fixtures for each of the mailers actions. If you didn't use the generator you'll have to make those files yourself.
When you generated your mailer, the generator creates stub fixtures for each of the mailers actions. If you didn't use the generator, you'll have to create those files yourself.
#### The Basic Test Case
...
...
@@ -1204,7 +1213,7 @@ Testing Jobs
------------
Since your custom jobs can be queued at different levels inside your application,
you'll need to test both jobs themselves (their behavior when they get enqueued)
you'll need to test both, the jobs themselves (their behavior when they get enqueued)
and that other entities correctly enqueue them.
### A Basic Test Case
...
...
@@ -1255,7 +1264,7 @@ end
Testing Time-Dependent Code
---------------------------
Rails provides inbuilt helper methods that enable you to assert that your time-sensitve code works as expected.
Rails provides inbuilt helper methods that enable you to assert that your time-sensitive code works as expected.
Here is an example using the [`travel_to`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/TimeHelpers.html#method-i-travel_to) helper: