Rails Testing: Migrations/Models/Fixtures

[Jason Edwards]

Apparently I have missed something somewhere along the line, and have
made a real mess of things here.

The question/problem I'm trying to work through is, in Rails, how do
you deal with a mixture of "code tables" and test fixtures. I'm not
sure what "code tables" are really called, but I'm referring to tables
containing data that's more like configuration. For example I've got
three tables named 'authorities', 'roles' and 'authorities_roles'
representing a many-to-many (habtm) relationship between authorities
and roles. The authorities table is essentially static, the records
will change very rarely (only when there's an update to the system).
The roles table has a set of default roles, and allows users to create
their own roles. Make sense?

Somewhere I thought I read that my "code table" data should be moved
out of the fixtures and into a migration. Easy enough. But now my
tests fail miserably. For one going from unit to functional tests,
all the records are deleted.

So how do you get the migrations and fixtures to play well together?

Jason

[Ceaser Larry]

You need the data in both places. In the fixtures and in the migration
script.

Ceaser

[Jason Edwards]

Well that won't work. You can't follow the DRY principle if you do that...

Jason

[Jamis Buck]

Not sure what you mean by that, Jason. The migration puts the data
into your "live" database (production, or development). The fixtures
put the data into your test database. If the data will always be the
same in both places, have your migration read the fixtures.

- Jamis

[Jason Edwards]

Derr, have the migrations read the fixtures, now I'm pickin' up what
you're layin' down... I'll give that a whirl.

Thanks,

Jason

[Brett Rasmussen]

Out of curiosity, what would I do if I wanted to load the fixtures into the development database but don't want it part of a migration?

Brett

[Tieg Zaharia]

"rake db:fixtures:load FIXTURES=trains,plains,automobiles"

(and add RAILS_ENV=???) if you want to load it into a specific environment,


tieg

[Ben Mabey]

rake db:fixtures:load # Load fixtures into the current
environment's database. Load specific fixtures using FIXTURES=x,y

For a complete listing of rake tasks that ships with rails do "rake
-T". So if you want to load the fixtures into dev you would do:
RAILS_ENV=development rake db:fixtures:load

-Ben

[Jason Edwards]

So I finally got it all working, just the way I wanted, but I didn't
follow the advice I got. Please feel free to tell me how lame this
is.

* I'm still loading my base data sets as inserts in my migrations.
* My fixture files now contain *only* test fixtures, none of the base data.
* I set the 'self.pre_loaded_fixtures = true' and
'self.use_transactional_fixtures = true' in my test_helper.rb
* I took out all the fixture declarations in my test, and now have
them load fixtures from the database.
* I wrote a rake task which loads the fixtures, but doesn't delete the
existing data. So I can insert data into a table in my migration, and
then insert additional rows in table using the fixtures.

Now the only problem I'm having is when I run the tests with Rake, it
calls 'db:test:prepare' which recreates the structure, but leaves the
tables empty.

Anyone know how to change that? I was just going to write another Rake task...

Jason

P.S. - If you care, you can find the rake task on my blog:
http://www.jtanium.com/blog/?p=41

[Lee Jensen]

Can't say I can tell you how to change that, but I would advise
against having a test database that can't be torn down and rebuilt at
a whim from your fixtures without breaking any tests. It'll make your
life easier in the long run. Not tearing down your test database each
time can leave you with extremely difficult to track down errors,
false negatives and false positives and generally make your tests
harder to use and less reliable.

Lee

[Jason Edwards]

It's not that it can't be torn down, I can tear it down, and rebuild
it easily, I do it dozens of times a day. The problem is the default
Rake task ('test') doesn't use my migrations, and my
load_additional_fixtures task, to rebuild the test database.

In the short term I wrote a simple one-liner shell script to do
exactly what I'm talking about, but now I realize that a new Rake task
is definitely the way to go.

Thanks,

Jason

P.S. - In case you didn't get the memo: Ruby (metaclasses in this
case) rules! Long live Ruby!