Testing Mailers

The first thing to check when testing your project sends e-mails is that your project is not sending them when you are testing. Rails does this by default by a setting in config/environments/test.rb:

  config.action_mailer.delivery_method = :test

Compare to the line in config/environments/development.rb

  config.action_mailer.delivery_method = :smtp

Setting this to test stops e-mails being sent, and instead they are sent to an array, ActionMailer::Base.deliveries. This array is reset before each test, by the way.

Here is a simple mailer to test.

class Notifier < ActionMailer::Base
  default :from => "DB@mysite.com"
  add_template_helper(ApplicationHelper)
  
  # Sets up an e-mail for notifying the user to activate his account.
  def signup_notification user
    @name = user.username
    @login = user.login
    @url  = "http://mysite.com/activate/#{user.activation_code}"
    mail :to => user.email, :subject => 'Activate your account'
  end

  def page_error(err, request)
    @err = err
    @request = request
    mail :to => 'admin@mysite.com', :subject => 'Page error'
  end
end

In your controller, you might invoke the first like this:

  Notifier.signup_notification(@user).deliver

In the test, you will need to break that up, so you can examine the mail object.

class NotifierTest < ActionMailer::TestCase
  test "signup_notification" do
    # Create a mock user
    user = TestUser.new 'tester', 'tester@nowhere.com'
    # Invoke the mailer method
    mail = Notifier.signup_notification user
    # Deliver the mail
    mail.deliver
    # Check the mail got sent
    assert !ActionMailer::Base.deliveries.empty?
    # Check it is the right mail
    assert_equal 'Activate your account', mail.subject
    assert_equal ["tester@nowhere.com"], mail.to
    assert_equal ["DB@mysite.com"], mail.from
    assert_match "Visit this url to activate your account",
                    mail.body.encoded
  end
end

Here is the TestUser definition.

class TestUser
  attr_reader :username, :email, :login

  def initialize username, email
    @username = username
    @email = email
    @login = username.gsub ' ', ''
  end
  
  def activation_code; "abcd"; end
end

The second method in the mailer above is for sending error reports to the administrator. Here is a method that generates an error, and sends that to the mailer:

  test "page_error" do
    request = TestRequest.new
    begin
      raise "A test error"
    rescue Exception => err
      mail = Notifier.page_error(err, request)
      mail.deliver
      assert !ActionMailer::Base.deliveries.empty?
      assert_equal "Page error", mail.subject
      assert_equal ["admin@mysite.com"], mail.to
      assert_equal ["DB@mysite.com"], mail.from
      assert_match "error encountered!", mail.body.encoded
    end
  end

Here is the TestRequest definition; it simply returns the string "good" if the method name is recognised - that is enough for the mailer to wok with, and will still highlight any mistyped or made-up method names.

class TestRequest
  # Returns the string "good" if the method is recognised
  def method_missing method, *args
    return "good" if [:fullpath, :request_method, :query_parameters,
                      :request_parameters, :referer].include? method
    super  
  end
end

end

Testing Protected Methods in a Controller, Part 2

See part 1 here.

Unit Testing Controller Methods

You are not obliged to test controller methods in with your functional tests. You can mix them in with your unit tests, though they do need a separate class (and so ideally a separate file). The trick is to sub-class from ActionController::TestCase, and to then nominate a controller you are testing (this is normally derived from the test name, so would not be necessary if you maintain the naming convention):

class DrumsControllerMethodsTest < ActionController::TestCase
  tests DrumLog::DrumsController

  # tests
end

Whether this is a good idea is debatable. I would argue that testing these protected methods is proper unit testing, and is not functional testing, so that suggests they should be with the rest of the unit tests (as your helper tests already are), however, I think I read that in Rails 4 they will be relabelled as model tests and controller tests, which kind of undermines that argument.

One solution is to move them to a library file (create a module, and include it in ApplicationController), then you can unit test them with your other library files. Obviously this works best for more generic methods.

Using A Mock Controller

Sometimes you want test methods that invoke methods like render and redirect_to that are doing all sorts of things behind the scenes. Better (in my opinion) to create a mock controller, and over-write these methods.

Here is an example. It is testing a method check_security_level (a filter in fact) that will send the user to the log-in page if he tries to access the edit page when not logged in, but does nothing if he tries to access the index page.

# Create a mock class to subvert redirect_to,

# inheriting from ApplicationController.
# You could inherit an actual controller class.
class MockSampleController < ApplicationController
  attr_reader :destination
  
  # Redefine direct_to to just note the destination and do nothing more.
  def redirect_to s; @destination = s; end
end



class MyControllerTest < ActionController::TestCase
  tests MockSampleController
  
  # First test, check_security_level should redirect the user to a login page
  def test_check_security_level_1
    # Set the request parameters (must be strings not symbols)
    @controller.params[:action] = 'edit'  
    @controller.send(:check_security_level)
    assert_equal '/user_log/sessions', @controller.destination[:controller]
  end

  # Second test, check_security_level should do nothing
  def test_check_security_level_2
    @controller.params[:action] = 'index'  
    @controller.send(:check_security_level)
    assert_nil @controller.destination
  end
end

Add New Routing For Tests

Sometimes you want to create a mock controller with its own set of actions for testing methods in your controllers. This is not trivial as you need to have a set of routes for your test actions, and it is bad practice to put them into routes.rb, as they will end up in your production environment.

Creating a routes.rb for testing is not ideal, as it will get out of sync with the real routes.rb, and there is no simple way to append new routes (the Application.routes.draw method clears all existing routes).

The solution is to use the with_routing method, which is a standad part of Rails. However, it is somewhat neglected, as the API shows...

This is the example from 2.3.8, when it was in  ActionController::TestProcess:
http://apidock.com/rails/ActionController/TestProcess/with_routing

 with_routing do |set|
    set.draw do |map|
      map.connect ':controller/:action/:id'
        assert_equal(
          ['/content/10/show', {}],
          map.generate(:controller => 'content', :id => 10, :action => 'show')
      end
    end
  end

Spot the missing right bracket to match the one in "assert_equal("?

In Rails 3 it got moved to ActionDispatch::Assertions::RoutingAssertions...

 with_routing do |set|
    set.draw do |map|
      map.connect ':controller/:action/:id'
        assert_equal(
          ['/content/10/show', {}],
          map.generate(:controller => 'content', :id => 10, :action => 'show')
      end
    end
  end

Still missing that right bracket. And still using Rails 2 style routing!

Here is an example that works:

  def test_render_generic_form
    with_routing do |set|
      set.draw do
        resources :mocks do
          collection do
            get :test_action
          end
        end
      end
    
    
      get :test_action
      # assertions
    end
  end