README

Path: README
Last Update: Thu Apr 16 05:09:16 -0400 2009

FixtureReplacement

What is FixtureReplacement

FixtureReplacement is a Rails plugin that provides a simple way to quickly populate your test database with model objects without having to manage multiple, brittle fixture files. You can easily set up complex object graphs (with models which reference other models) and add new objects on the fly.

Not only can FixtureReplacement make your test data easier to maintain, it can also help to make your tests and specs much more readable and intention-revealing by allowing you to omit extraneous details and focus only on the attributes that are important for a particular behaviour. It works well with both RSpec and Test::Unit.

What‘s new in 2.1:

See the CHANGELOG.

Most notably, String.random is gone in favor of the method random_string. Call random_string as you would previously in FixtureReplacement:

  module FixtureReplacement
    attributes_for :user do |u|
      u.username = random_string
    end
  end

To replace calls to String.random in your specs or elsewhere, use the FixtureReplacement module instead:

  FixtureReplacement.random_string

  # or:

  FR.random_string # FR is a convenience alias for FixtureReplacement

How to use FixtureReplacement

Defining default attributes

At the heart of FixtureReplacement is the db/example_data.rb file where you define the default attributes for each of your test models. This example shows the default attributes for a user:

  module FixtureReplacement

    attributes_for :user do |u|
      password = random_string

      u.value                  = "a value",
      u.other                  = "other value",
      u.another                = random_string,     # random string 10 characters long
      u.one_more               = random_string(15), # 15 characters long
      u.password               = password,
      u.password_confirmation  = password,
      u.associated_object      = default_bar        # expects attributes_for :bar to be setup
    end

  end

Note that:

  • A ‘random_string’ method is provided for attributes whose exact value isn‘t important; this means you can create multiple, unique model instances
  • you can perform arbitrary set-up and execute any Ruby code prior to returning the hash (as shown here where a password is generated and then used for both the :password and :password_confirmation attributes)
  • a default_modelname method is automatically provided that allows you to set up dependent model objects (in this case an instance of the Bar model)

Available methods

Based on the above definition FixtureReplacement makes the following methods available:

  • random_string: generates a random string as shown above
  • new_user: equivalent to User.new with the attributes for the user.
  • create_user: equivalent to User.create! with the user‘s attributes.
  • default_user: for use inside model_attributes definitions; this basically returns a Proc object which allows the actual creation of the object to be deferred until it is actually needed: in this way unnecessary object creation is avoided until it is known for sure that a particular attribute is not going to be overridden.

Overriding attributes

Overrides of specific attributes can be performed as follows:

  new_user(:thing => "overridden")
  create_user(:thing => "overridden")

Overrides can also be used with associations:

  scott = create_user(:username => "scott")
  post = create_post(:user => scott)

attr_protected / attr_accessible

In the case that the model has an attr_protected field, FixtureReplacement will assign the field as if it wasn‘t protected, which is convenient for testing:

  class User < ActiveRecord::Base
    attr_protected :admin_status
  end

  user = create_user(:username => "scott", :admin_status => true)
  user.admin_status # => true

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 :each 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.

Installation

  Install the plugin:

    git://github.com/smtlaissezfaire/fixturereplacement.git

Using FixtureReplacement within script/console

  $ ./script/console
  Loading development environment
  >> include FR
  => Object
  >> create_user
  => #<User id: 1, crypted_password: "521faec1c095..." ...>

Using it with RSpec

Add the following to your spec/spec_helper.rb file, in the configuration section:

  Spec::Runner.configure do |config|
    config.include FixtureReplacement
  end

Using it with Test::Unit

Add the following to your test/test_helper.rb file:

  class Test::Unit::TestCase
    include FixtureReplacement
  end

Running the Specs/Tests for FixtureReplacement

You will need rspec (version 1.0.8 or later) to run the specs, as well as the sqlite3-ruby gem (and sqlite3 installed):

  % sudo gem install rspec
  % sudo gem install sqlite3-ruby

cd into the fixture_replacement plugin directory:

  % cd vendor/plugins/fixture_replacement

Then run with <tt>rake<tt>

  % rake

There are also some tests for test/unit. These mainly serve as regressions, but you are free to run them as well.

Specdocs

Specdocs can be found here

The Rcov report can be found here

A flog report can be found here

Patches, Contributions:

Thanks to the following for making this software better:

  • Greg Bluvshteyn (www.m001.net), for bugging me about the naming, and making the wonderful suggestion to use the plugin in the console.
  • Simon Peter Nicholls
    • default_* methods can take a hash (applied in rev. 11)
  • Wincent Colaiuta (wincent.com/) - Huge Thanks
    • patch for spelling error in comments (applied in revision 31)
    • patch for specs with sqlite3 (applied in revision 35)
    • patch to ignore attr_protected in mass assignment (applied in revision 57)
    • Most of this README Documentation (applied in revision 62)
    • patch: silencing sqlite3 in memory creation of table output (applied in revision 72)
  • Carl Porth
    • patch: classify should be camelize (applied in revision 74)
  • LinoJ, JW, Matthew Bass, Andy Watts, Dave Spurr
    • bug reports
  • Brian Helmkamp: Our mutual hate of ActiveRecord

If you would like to change how this software works, please submit a patch with specs through the lighthouse project page:

fixture_replacement.lighthouseapp.com/

License

This software is dual licensed under the MIT and the GPLv3 Licenses (it‘s your pick).

Copyright 2007-2009 Scott Taylor <scott@railsnewbie.com>

[Validate]