philosophy_and_bugs.rdoc

Motivation Behind FixtureReplacement¶ ↑

As Dan Manges has outlined in his blog post, “Fixing Fixtures with Factory” (www.dcmanges.com/blog/38), this approach to generating test data has a number of advantages:

• The factory provides default values and relationships

• Invalid data will never be loaded into your test database, as it is with the typical YAML fixture. A record which is created with a create_* method (create_user, create_post, etc.) uses ActiveRecord’s create! behind the scenes, so any invalid data will raise a clear error. This means that you will spend your time debugging your tests and code, not your test data.

• It’s in Ruby, so you won’t have to fight with YAML’s spacing issues, plus the data is by nature more dynamic and more agile.

• When a test fails (and they will), someone who hasn’t written the test will be able to figure out the intention behind the test. They won’t have to go digging through YAML files to figure out the relevant data to the test.

• No more opening of 5 different YAML files to see the associations and column names of different models - this is conveniently located in one file (db/example_data.rb)

• If you set use_transactional_fixtures = true in your test_helper or spec_helper (and you really should be using this), the data that is created in each test will be rolled back, meaning no-side effects, and a consistent database among different developers, and for your self during different test runs.

Random Data in db/example_data.rb¶ ↑

The use of random data should also be spoken of. Many may think this to be dangerous, but in fact random data is often helpful. Consider the following snippets of psudo-code (along with it’s test):

# apps/models/user.rb :
# ----------------------

class User < ActiveRecord::Base
  validates_uniqueness_of :username
  validates_presence_of :password

  after_create :check_password

private

  def check_password
    # ...
  end

public

  def establish_friendship_with(other_user)
    # ...
  end

  def friends
    # ...
  end
end

# The test:
# ---------

def test_make_sure_user_can_establish_friendship
  @user_one = User.create({
    :username              => "foo",
    :password              => "some password",
    :password_confirmation => "some password_confirmation"
  })

  @user_two = User.create({
    :username              => "bar",
    :password              => "some password",
    :password_confirmation => "some password confirmation"
  })

  @user_one.establish_friendship_with(@user_two)
  @user_one.friends.should == [@user_two]
end

Notice that the above test adds a lot of extra noise in getting valid users into the database; The test, however, doesn’t care what the usernames are, that the password is a good one, that the password matches the password confirmation, and so on. The point of the test is not to check those things, but rather that a friendship can be established.

Here would be a similar test with the FixtureReplacement:

# The test:
# ---------

before do
  @user_one = create_user
  @user_two = create_user
end

def test_make_sure_user_can_establish_friendship
  @user_one.establish_friendship_with(@user_two)
  @user_one.friends.should == [@user_two]
end

Once again, the test above doesn’t care about usernames, so why should you? But to even store those two users into the database, you will need unique usernames, as well as password which match. Here is where the random data comes in:

# db/example_data.rb
# -------------------

module FixtureReplacement
  attributes_for :user do |u|
    password = random_string

    u.username              = random_string
    u.password              = password
    u.password_confirmation = password
  end
end

Now, in a different test case, if you do care about the usernames not being random, it is easy to set them:

create_user({
  :username              => "scott",
  :password              => "foobar",
  :password_confirmation => "foobar"
})

Disadvantages of FixtureReplacement¶ ↑

The one major disadvantage behind this approach is that it’s slow - just as slow as fixtures, if not slower. One approach that the rspec crowd is using is to use this plugin in integration tests, while using mocks & stubs in model unit tests. It’s not a big deal if your integration tests run slow, since you probably don’t run them very often.

Another approach is to look to external sources to speed up your test suite:

• a sqlite3 in-memory database (can cut your test/spec time in half)

• unit-record gem (by Dan Manges), which takes advantage of multi-core processors

• a distributed build system, such as spec_distributed

• running tests individually, or per file

• A faster machine

If you have other ideas for speeding up your test suite, I’m all ears.