Why no fixtures?

In the User tests for Tasty, I showed how to use fixtures just because its inevitable that you'll encounter them while working with Rails. However, it turns out that they've got a few sticky spots, and a lot of times, you simply don't need them.

By just explicitly calling Entry.new and Entry.create, it's very clear what our tests are checking for, and it's also reflecting how the code will actually be used, rather than relying on the implementation details of fixtures.

Making ugly assertions pretty via test_helper.rb

At the very top of your test, you see that rails requires the test_helper file. This is used for providing functions to simplify your tests and make them cleaner. One of the most common ways of doing this is to create custom assertions.

For example, it would be nice to have an assert_not_valid to match the assert_valid call in our tests. This is very easy to write:

test/test_helper.rb

# other code omitted
# add more helper methods to be used by all tests here...

  def assert_not_valid(model,msg="record was valid but shouldn't be")
    assert_block(msg) { !model.valid? }
  end

# ...

This is using test/unit's assert_block method to display the given message when the block returns false, and otherwise, pass the test if the block returns true.

This means that our old assertion:

assert !e.valid?, "Should not save entry unless url is unique"

now would look like this:

assert_not_valid e, "Should not save entry unless url is unique"

Custom assertions can become arbitrarily complex, and help keep your tests easily readable and focused on the actual things you are trying to verify. Since they are shared between all your tests, you can begin to establish a very high level set of assertions if needed.

If you want to play with this a little more, you might want to create something like an assert_invalid_field method that would work as shown below, but I'll leave the implementation details to you.

  assert_invalid_field :url, :for => e

What About That Stuff in validate()?

You'd also need to test Entry's custom validation, as clearly no one should be creating entries mentioning Rube Goldberg. The reason I didn't give this special treatment in the discussion of testing validations is that you handle it exactly the same way:

  def test_validates_rube_goldberg_check
    e = Entry.new(:url => "google.com", :short_description => "Nothing")
    assert_valid e

    f = Entry.new(:url => "apple.com",
                  :short_description => "Has Rube Goldberg")

    assert_not_valid f, "Should not save entry" 
    assert f.errors.invalid?(:short_description),
           "Expected an error for Rube reference" 
  end

Testing domain logic

We've also got a few other things that need testing in our Entry model, namely the tagging convenience methods and the date formatting methods. You essentially want to use your tests to define how you expect these methods to be used, and how you expect them to behave. The result is a fairly clear form of organic, self-verifying documentation:

test/unit/entry_test.rb

  # ...

  def test_tagging
    # needs to be put in DB because we're dealing with associations
    e = Entry.create(:url => "http://smurfs.com")
    e.tag_as(:foo)

    assert e.tagged_as?(:foo)
    assert !e.tagged_as?(:bar)

    assert_equal [:foo], e.tag_names

    e.tag_as(:bar)
    assert_equal [:foo,:bar], e.tag_names
  end


  def test_date_format
    e = Entry.create(:url => "http://snakesonaplane.com")
    assert_match /\A\d{4}\.\d{2}\.\d{2}\Z/, e.created_date
    assert_match /\A\d{4}\.\d{2}\.\d{2}\Z/, e.updated_date
  end

  # ...

I'm hoping that the above is easy enough to read, even for beginners. It's worth noting that I use a pattern to match my date format rather than use a specific date. I trust Rails to populate the underlying fields correctly, I just want to make sure the format is as expected.

By now it should be fairly clear that you can rather easily cover the use cases for your model. Once you write the tests once, they will continue to protect you down the line. Units will save you tremendous effort during refactoring, as they can quickly lead you to the source of various problems, and to a concise set of use cases that are easy to read.

Take control with functional tests

While it's true that your data model is often going to be the heart of your application, they're not the only thing that needs testing. Since controllers are the vital link between your models and views, they're just as test-worthy as a model. Luckily, it's pretty easy to handle the most important cases.

Tasty already has two controller actions we can test, the index pages for both entries and tags. When we generated those controllers, Rails already generated functional tests.

These default tests are already successfully doing nothing, but let's change them to be a little more useful.

The following set of tests checks to make sure that we can simply hit the tags index, whether or not any tags exist in the database:

test/functional/tags_controller_test.rb

require File.dirname(__FILE__) + '/../test_helper'
require 'tags_controller'

# Re-raise errors caught by the controller.
class TagsController; def rescue_iction(e) raise e end; end

class TagsControllerTest < Test::Unit::TestCase
  def setup
    @controller = TagsController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new

    Tag.destroy_all
  end

  def test_index_non_empty_tags
    Tag.create(:name => "foo")
    Tag.create(:name => "bar")

    get :index
    assert_response :success

    # assigns() lets you access instance variables assigned by the controller.
    tagnames = assigns(:urls_for_tags).keys
    %w[foo bar].each { |n| assert tagnames.include?(n) }
  end

  def test_index_empty_tags
    get :index
    assert_response :success
  end
end

You'll notice that I call Tag.destroy_all in my setup. This is a workaround for the fact that when you run your unit and functional tests together, it seems as if the fixture data from the unit tests wants to linger. Another option would be to run rake test:functional instead of just rake, but I'm extremely lazy.

Dealing with forms

Though it's helpful to ensure you can at least successfully call an action, usually you'll be more interested in testing out form handling. We're going to design a simple Entry search feature test-first. Writing tests before code can be a very powerful technique, as it requires you to think about design right away rather than as an afterthought.

Let's start by setting up a test that makes sure that you can access a search action:

test/functional/entries_controller_test.rb

def test_search
  get :search
  assert_response :success
end

If you run the tests now, you'll notice this generated an error:

ActionController::UnknownAction: No action responded to search

In order to make this pass, we need to add an action to our entries controller, for now it doesn't need to do anything:

app/controllers/entries_controller.rb

class EntriesController < ApplicationController
  def index
    @entries = Entry.find(:all)
  end

  def search

  end
end

If you've already ran your tests after adding this chunk of code, you'll see that we're missing a template. For now that also doesn't need to do anything, it just needs to have an empty file at app/views/entries/search.rhtml.

Once you have that, the tests should be all green, and that means we can make them more interesting. This test adds the expectation that if we pass a parameter for a tag that doesn't exist, it will stick a notice in the flash object.

 def test_search
    get :search
    assert_response :success

    get :search, :tag => "not_here" 
    assert_equal "No Entries With Tag: not_here", flash[:notice]
  end

Here's the code that makes that pass:

def search
  if params[:tag]
    @entries = Tag.entries_by_name(params[:tag])
    unless @entries
      flash[:notice] = "No Entries With Tag: #{params[:tag]}" 
    end
  end
end

Now we only need to deal with one more case, successful search. Here's our full test:

def test_search
  get :search
  assert_response :success

  get :search, :tag => "not_here" 
  assert_equal "No Entries With Tag: not_here", flash[:notice]

  e = Entry.create(:url => "apple.com")
  f = Entry.create(:url => "alsoapple.com")
  e.tag_as("apple")
  f.tag_as("apple")

  get :search, :tag => "apple" 
  assert_equal "Showing 2 Matches For Tag: apple", flash[:notice]
end

This code will make it pass:

def search
  if params[:tag]
    @entries = Tag.entries_by_name(params[:tag])
    if @entries
      flash[:notice] = "Showing #{@entries.length} Matches For Tag: #{params[:tag]}" 
    else
      flash[:notice] = "No Entries With Tag: #{params[:tag]}" 
    end
  end
end

Time to move on

You're most of the way to having a functional little tag search together. It's not particularly elegant, but will suffice for showing some functional testing in action. I'll leave it as an exercise to the reader to hook up a proper view for this, but include my minimalistic one in the source package for Tasty.

The key thing to take away from functional tests is that they allow you to verify that your application is responding as expected to various requests, and that they map to your controller actions, providing a safety net for them and making it easier to refactor things down the line.

Integration testing, for the high-level stuff

Getting an incredibly realistic use case for integration testing into Tasty at this point would be tricky. The reason for this is that integration tests often take the form of "big picture" user stories. An ideal case might be something like "James logs in, James purchases the very last super cool robot. Sam tries to buy a super cool robot, but can't because James already scooped it up". We don't quite have room in this article to expand Tasty to that level.

That having been said, integration testing can be quite useful for when you're dealing with session data, even for simple things.

Anyone who's messed with testing sessions by hand in a browser without some extra supporting apps probably has inevitably felt some considerable pain.

We're going to add a simple feature to Tasty that lets users indicate which entry in the system is their "favorite." What this will demonstrate is that we can create two separate sessions in our tests which do not interfere with each other.

Let's start by generating some code:

 $ script/generate integration_test stories

The following integration test shows how to build a custom user object with some helper methods, borrowing a trick from Agile Web Development With Rails.

test/integration/stories_test.rb

require "#{File.dirname(__FILE__)}/../test_helper" 

class StoriesTest < ActionController::IntegrationTest
  def test_users_have_separate_favorite_entries

    populate_entries

    greg  = regular_user
    andra = regular_user

    greg.gets_a_random_favorite_entry

    greg_first = greg.favorite_entry

    andra.gets_a_random_favorite_entry

    # make sure session does not change after other user gets an entry.
    assert_equal greg_first, greg.favorite_entry
  end

  def regular_user
    open_session do |user|
      def user.favorite_entry
        session[:favorite]
      end

      def user.gets_a_random_favorite_entry
        get "/entries/random_favorite" 
        assert_response :success
        assert Entry.find(session[:favorite])
      end
    end
  end

  def populate_entries
    %w[abc.com def.org hij.net].each do |u|
      Entry.create(:url => u)
    end
  end

end

Our first failure happens as expected; it can't find the random_favorite action.

Expected response to be a <:success>, but was <404>

The following chunk of code should get you passing the tests, but be sure to add a view, even if it's empty.

app/controllers/entries_controller.rb

  def random_favorite
    session[:favorite] = rand(Entry.count) + 1
  end

From here, you'd probably want to consider moving this kind of feature down into the User model, after adding a way to login and identify yourself to Tasty. For now, it suffices as a way to show how you can build tests that run with independent sessions for your applications.

Another thing that integration tests are important for, as you get into more advanced situations, is for testing any interesting logic you may have in your routes. Functional tests bypass a lot of the routing stuff, so integration tests are about the only way to test them effectively.

I didn't bother building a view for this new feature, but you could probably just add something like a favorite? method to Entry which inspects the session data and does some interesting formatting in your view as needed.

The End of the Road, But Only the Tip of the Iceberg

Rails Testing is a very big topic. I hope that this article has at least shown by example the bare minimum necessary for you to know what the various kinds of tests are used for, and how to get everything hooked up. There are plenty of folks out there writing Rails apps that don't fire up a browser until they're ready to work on design. I'm not quite that macho, but I do enjoy spending more time in my preferred programming environment than in the browser.

As you get more into testing, you'll find no shortage of interesting topics that I omitted from this article. I recommend doing a deep dive into the resources scattered across the blogosphere, because in the end, this stuff really does make you more productive.

If you'd like to see tasty in its present state, please do download the latest source , and if you'd rather start with the same base I used to create this article, you can grab that instead.

Thanks for taking another deep dive with me, and have fun writing those tests!

Gregory Brown is a New Haven, CT based Rubyist who spends most of his time on free software projects in Ruby. He is the original author of Ruby Reports.

Return to O'Reilly Ruby.

Copyright © 2009 O'Reilly Media, Inc.