Handling Non-User data in Rails tests

Question

We have a ton of non-user data: 500 product types that haven't changed in 20 years, 200GB of geospatial data that never changes (Queens is always 40.73N/73.82W)... etc. It's the same in Development and Production. It should be the same in Test, but the during testing Rails empties all of the test tables, and it takes a ton of time to re-populate during testing.

What is the Rails way to partition this non-user data so that it doesn't have to be repopulated in Test?

Answer 1

The documentation for this is found in the Fixtures class. (Search for "Transactional fixtures" on that page.)

The example they give starts out like this:

class FooTest < ActiveSupport::TestCase
    self.use_transactional_fixtures = true
    self.use_instantiated_fixtures = false
    ...

One of the projects I work on uses a test database with zero fixtures, so we just define this globally in test_helper.rb.

class ActiveSupport::TestCase
  self.use_transactional_fixtures = true
  self.use_instantiated_fixtures  = false
end

Answer 2

Hi Kirk,

jdl shows you the settings to use for enabling and disabling transactional_fixtures, you should be able to set:

# Use self in ActiveSupport::TestCase if you don't have a config block
# in test/test_helper.rb
#
config.use_transactional_fixtures = false

And stop Rails from trying to load fixtures before each run of your tests. The downside is you can't assume all your fixtures are loaded into the DB.

Real Answer

You have too much data in your fixtures. The Railsy thing to do it load only the necessary data in test fixtures; You do not need 200G of geospatial data (what freaking dataset is that anyway? that sounds way too big), and you probably don't need all 500 products.

Tests are for your code, so only include the few geospatial points you need for a test, or only include a few products with unique properties. Keep the DB light enough to be loaded quickly.

Your test fixtures should be separate from you application bootstrapping data, take advantage of that.

Real Real Answer

Don't touch the database in your tests (or, touch it very little). The database is slow and fixtures are difficult or impossible to maintain well. Instead, try using a stubbing framework like Mocha or flexmock. It's faster, and makes your tests read in a clearer manner. Tests are for code, you can stub the database out of the situation and trust that ActiveRecord works (because...it's tested too! :-).

If you do choose to stick with fixtures, I recommend using factory_girl instead of the built in Rails fixtures. You'll have a much better starting point.