Skip to content
This repository
Browse code

move mailer testing examples into the testing guide.

Closes #9325.

I adjusted the example and the description in the testing guide and
simply linked from the mailer to the testing guide. This way we don't
have to maintain two separate places.
  • Loading branch information...
commit b662cb89ce03e094215713d25d2df9fd5a4ecf88 1 parent 1d45419
Yves Senn authored March 25, 2013
27  guides/source/action_mailer_basics.md
Source Rendered
@@ -564,31 +564,8 @@ config.action_mailer.smtp_settings = {
564 564
 Mailer Testing
565 565
 --------------
566 566
 
567  
-By default Action Mailer does not send emails in the test environment. They are just added to the `ActionMailer::Base.deliveries` array.
568  
-
569  
-Testing mailers normally involves two things: One is that the mail was queued, and the other one that the email is correct. With that in mind, we could test our example mailer from above like so:
570  
-
571  
-```ruby
572  
-class UserMailerTest < ActionMailer::TestCase
573  
-  def test_welcome_email
574  
-    user = users(:some_user_in_your_fixtures)
575  
-
576  
-    # Send the email, then test that it got queued
577  
-    email = UserMailer.welcome_email(user).deliver
578  
-    assert !ActionMailer::Base.deliveries.empty?
579  
-
580  
-    # Test the body of the sent email contains what we expect it to
581  
-    assert_equal [user.email], email.to
582  
-    assert_equal 'Welcome to My Awesome Site', email.subject
583  
-    assert_match "<h1>Welcome to example.com, #{user.name}</h1>", email.body.to_s
584  
-    assert_match 'you have joined to example.com community', email.body.to_s
585  
-  end
586  
-end
587  
-```
588  
-
589  
-In the test we send the email and store the returned object in the `email` 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.
590  
-
591  
-NOTE: The `ActionMailer::Base.deliveries` array is only reset automatically in `ActionMailer::TestCase` tests. If you want to have a clean slate outside Action Mailer tests, you can reset it manually with: `ActionMailer::Base.deliveries.clear`
  567
+You can find detailed instructions on how to test your mailers in our
  568
+[testing guide](testing.html#testing-your-mailers).
592 569
 
593 570
 Intercepting Emails
594 571
 -------------------
35  guides/source/testing.md
Source Rendered
@@ -927,19 +927,24 @@ require 'test_helper'
927 927
 class UserMailerTest < ActionMailer::TestCase
928 928
   tests UserMailer
929 929
   test "invite" do
930  
-    @expected.from    = 'me@example.com'
931  
-    @expected.to      = 'friend@example.com'
932  
-    @expected.subject = "You have been invited by #{@expected.from}"
933  
-    @expected.body    = read_fixture('invite')
934  
-    @expected.date    = Time.now
935  
-
936  
-    assert_equal @expected.encoded, UserMailer.create_invite('me@example.com', 'friend@example.com', @expected.date).encoded
  930
+    # Send the email, then test that it got queued
  931
+    email = UserMailer.create_invite('me@example.com',
  932
+                                     'friend@example.com', Time.now).deliver
  933
+    assert !ActionMailer::Base.deliveries.empty?
  934
+
  935
+    # Test the body of the sent email contains what we expect it to
  936
+    assert_equal ['me@example.com'], email.from
  937
+    assert_equal ['friend@example.com'], email.to
  938
+    assert_equal 'You have been invited by me@example.com', email.subject
  939
+    assert_equal read_fixture('invite').join, email.body.to_s
937 940
   end
938  
-
939 941
 end
940 942
 ```
941 943
 
942  
-In this test, `@expected` is an instance of `TMail::Mail` that you can use in your tests. It is defined in `ActionMailer::TestCase`. The test above uses `@expected` to construct an email, which it then asserts with email created by the custom mailer. The `invite` fixture is the body of the email and is used as the sample content to assert against. The helper `read_fixture` is used to read in the content from this file.
  944
+In the test we send the email and store the returned object in the `email`
  945
+variable. We then ensure that it was sent (the first assert), then, in the
  946
+second batch of assertions, we ensure that the email does indeed contain what we
  947
+expect. The helper `read_fixture` is used to read in the content from this file.
943 948
 
944 949
 Here's the content of the `invite` fixture:
945 950
 
@@ -951,9 +956,17 @@ You have been invited.
951 956
 Cheers!
952 957
 ```
953 958
 
954  
-This is the right time to understand a little more about writing tests for your mailers. The line `ActionMailer::Base.delivery_method = :test` in `config/environments/test.rb` sets the delivery method to test mode so that email will not actually be delivered (useful to avoid spamming your users while testing) but instead it will be appended to an array (`ActionMailer::Base.deliveries`).
  959
+This is the right time to understand a little more about writing tests for your
  960
+mailers. The line `ActionMailer::Base.delivery_method = :test` in
  961
+`config/environments/test.rb` sets the delivery method to test mode so that
  962
+email will not actually be delivered (useful to avoid spamming your users while
  963
+testing) but instead it will be appended to an array
  964
+(`ActionMailer::Base.deliveries`).
955 965
 
956  
-This way, emails are not actually sent, simply constructed. The precise content of the email can then be checked against what is expected, as in the example above.
  966
+NOTE: The `ActionMailer::Base.deliveries` array is only reset automatically in
  967
+`ActionMailer::TestCase` tests. If you want to have a clean slate outside Action
  968
+Mailer tests, you can reset it manually with:
  969
+`ActionMailer::Base.deliveries.clear`
957 970
 
958 971
 ### Functional Testing
959 972
 

0 notes on commit b662cb8

Please sign in to comment.
Something went wrong with that request. Please try again.