aboutsummaryrefslogtreecommitdiffstats
path: root/guides
diff options
context:
space:
mode:
Diffstat (limited to 'guides')
-rw-r--r--guides/source/action_mailer_basics.md2
-rw-r--r--guides/source/autoloading_and_reloading_constants.md2
-rw-r--r--guides/source/testing.md6
3 files changed, 6 insertions, 4 deletions
diff --git a/guides/source/action_mailer_basics.md b/guides/source/action_mailer_basics.md
index 469fa171bc..df74b4ebd0 100644
--- a/guides/source/action_mailer_basics.md
+++ b/guides/source/action_mailer_basics.md
@@ -168,7 +168,7 @@ view and sending it over the HTTP protocol, they are just sending it out through
the email protocols instead. Due to this, it makes sense to just have your
controller tell the Mailer to send an email when a user is successfully created.
-Setting this up is painfully simple.
+Setting this up is simple.
First, let's create a simple `User` scaffold:
diff --git a/guides/source/autoloading_and_reloading_constants.md b/guides/source/autoloading_and_reloading_constants.md
index b3f923a017..7dfc39e192 100644
--- a/guides/source/autoloading_and_reloading_constants.md
+++ b/guides/source/autoloading_and_reloading_constants.md
@@ -798,7 +798,7 @@ to load a file using the current [loading mechanism](#loading-mechanism), and
keeping track of constants defined in that file as if they were autoloaded to
have them reloaded as needed.
-`require_dependency` is rarely needed, but see a couple of use-cases in
+`require_dependency` is rarely needed, but see a couple of use cases in
[Autoloading and STI](#autoloading-and-sti) and [When Constants aren't
Triggered](#when-constants-aren-t-missed).
diff --git a/guides/source/testing.md b/guides/source/testing.md
index 623380970e..93372b5c26 100644
--- a/guides/source/testing.md
+++ b/guides/source/testing.md
@@ -1012,7 +1012,7 @@ Finally we can assert that our response was successful and our new article is re
#### Taking it further
-We were able to successfully test a very small workflow for visiting our blog and creating a new article. If we wanted to take this further we could add tests for commenting, removing articles, or editing comments. Integration tests are a great place to experiment with all kinds of use-cases for our applications.
+We were able to successfully test a very small workflow for visiting our blog and creating a new article. If we wanted to take this further we could add tests for commenting, removing articles, or editing comments. Integration tests are a great place to experiment with all kinds of use cases for our applications.
Functional Tests for Your Controllers
@@ -1722,7 +1722,9 @@ within a model:
```ruby
require 'test_helper'
-class ProductTest < ActiveJob::TestCase
+class ProductTest < ActiveSupport::TestCase
+ include ActiveJob::TestHelper
+
test 'billing job scheduling' do
assert_enqueued_with(job: BillingJob) do
product.charge(account)