aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/testing.md
diff options
context:
space:
mode:
Diffstat (limited to 'guides/source/testing.md')
-rw-r--r--guides/source/testing.md33
1 files changed, 21 insertions, 12 deletions
diff --git a/guides/source/testing.md b/guides/source/testing.md
index 652030a733..7741834153 100644
--- a/guides/source/testing.md
+++ b/guides/source/testing.md
@@ -123,7 +123,7 @@ def test_the_truth
end
```
-However only the `test` macro allows a more readable test name. You can still use regular method definitions though.
+Although you can still use regular method definitions, using the `test` macro allows for a more readable test name.
NOTE: The method name is generated by replacing spaces with underscores. The result does not need to be a valid Ruby identifier though, the name may contain punctuation characters etc. That's because in Ruby technically any string may be a method name. This may require use of `define_method` and `send` calls to function properly, but formally there's little restriction on the name.
@@ -610,9 +610,9 @@ For creating Rails system tests, you use the `test/system` directory in your
application. Rails provides a generator to create a system test skeleton for you.
```bash
-$ bin/rails generate system_test users_create_test
+$ bin/rails generate system_test users_create
invoke test_unit
- create test/system/users_create_test.rb
+ create test/system/users_creates_test.rb
```
Here's what a freshly-generated system test looks like:
@@ -620,10 +620,12 @@ Here's what a freshly-generated system test looks like:
```ruby
require "application_system_test_case"
-class UsersCreateTest < ApplicationSystemTestCase
- visit users_url
-
- assert_selector "h1", text: "Users"
+class UsersCreatesTest < ApplicationSystemTestCase
+ # test "visiting the index" do
+ # visit users_creates_url
+ #
+ # assert_selector "h1", text: "UsersCreate"
+ # end
end
```
@@ -642,7 +644,7 @@ system tests should live.
If you want to change the default settings you can simply change what the system
tests are "driven by". Say you want to change the driver from Selenium to
-Poltergeist. First add the Poltergeist gem to your Gemfile. Then in your
+Poltergeist. First add the `poltergeist` gem to your Gemfile. Then in your
`application_system_test_case.rb` file do the following:
```ruby
@@ -656,8 +658,8 @@ end
The driver name is a required argument for `driven_by`. The optional arguments
that can be passed to `driven_by` are `:using` for the browser (this will only
-be used for non-headless drivers like Selenium), `:on` for the port Puma should
-use, and `:screen_size` to change the size of the screen for screenshots.
+be used for non-headless drivers like Selenium), and `:screen_size` to change
+the size of the screen for screenshots.
```ruby
require "test_helper"
@@ -720,7 +722,7 @@ class ArticlesTest < ApplicationSystemTestCase
end
```
-The test should see that there is an h1 on the articles index and pass.
+The test should see that there is an `h1` on the articles index page and pass.
Run the system tests.
@@ -728,6 +730,9 @@ Run the system tests.
bin/rails test:system
```
+NOTE: By default, running `bin/rails test` won't run your system tests.
+Make sure to run `bin/rails test:system` to actually run them.
+
#### Creating articles system test
Now let's test the flow for creating a new article in our blog.
@@ -758,7 +763,7 @@ text. Once the fields are filled in, "Create Article" is clicked on which will
send a POST request to create the new article in the database.
We will be redirected back to the the articles index page and there we assert
-that the text from the article title is on the articles index page.
+that the text from the new article's title is on the articles index page.
#### Taking it further
@@ -1435,6 +1440,10 @@ variable. We then ensure that it was sent (the first assert), then, in the
second batch of assertions, we ensure that the email does indeed contain what we
expect. The helper `read_fixture` is used to read in the content from this file.
+NOTE: `email.body.to_s` is present when there's only one (HTML or text) part present.
+If the mailer provides both, you can test your fixture against specific parts
+with `email.text_part.body.to_s` or `email.html_part.body.to_s`.
+
Here's the content of the `invite` fixture:
```