My recommendation would be to not pre-populate with a migration. I would create a ruby script for that and have developers run that script to get setup. Then I would run that script in the test/test_helper.rb setup or where ever is appropriate if I wanted that data available in my tests.
A more conventional approach would be to create fixtures with the test data. Then you can load those fixtures into your development database with “rake db:fixtures:load”.
What's strange to me is the idea that Rails testing is not
comprehensive, i.e., there are constants, e.g., zip codes, that you
will use in production that you didn't have access to in testing.
While I appreciate that testing is built on cases and not exhaustive,
I can think of situations in my developing app where I might like to
check for "surprises" and I won't want contrived cases derived from
fixtures or factories. I guess what I'm getting at here is the idea
that testing might involve statistical checks, e.g., what is the
probability that I get some certain result? If I get many low
probability results, maybe something's wrong with my constants or the
way I'm handling them, e.g., zip codes. Anyway, this concern straddles
the line between uncertainty about inputs, e.g., app constant data
like zip codes, and outputs -- what an app does with them.
Thanks for your comments, I consider my question well answered.
My recommendation would be to not pre-populate with a migration. I
would
create a ruby script for that and have developers run that script to get
setup. Then I would run that script in the test/test_helper.rb setup or
where ever is appropriate if I wanted that data available in my tests.
Yes. In fact, Rails 2.3 has seeding built in, and for older versions,
there's seed-fu.
Seed data does not belong in migrations.
A more conventional approach would be to create fixtures with the test
data. Then you can load those fixtures into your development database
with
"rake db:fixtures:load".
No. Fixtures are a broken feature of Rails and should be avoided at all
costs. Use factories instead.