Don’t do it.
And not just because you should be using rspec.
rake db:schema:load
test does this:
** Invoke db:schema:load (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:schema:load ** Invoke test (first_time) ** Execute test ** Invoke test:units (first_time) ** Invoke test:prepare (first_time) ** Invoke db:test:prepare (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment ** Execute db:abort_if_pending_migrations ** Execute db:test:prepare ** Invoke db:test:load (first_time) ** Invoke db:test:purge (first_time) ** Invoke environment ** Execute db:test:purge ** Execute db:test:load ** Invoke db:schema:load ** Execute test:prepare ** Execute test:units ** Invoke test:functionals (first_time) ** Invoke test:prepare ** Execute test:functionals
If you look closely, you’ll see that db:schema:load is in there twice. The first time, it’s loading into your dev environment. The second time, it’s loading into your test environment. Or, tries to: rake notices that db:schema:load was already run, so it skips it. You know, unnecessary extra work.
I am most likely to rake db:schema:load test
(or spec) on a CI server, sometimes with a db:migrate mixed in. One-liner ci scripts are nice. But keep db:schema:load and test separated.
If you have db/schema.rb in source control like you should, and you keep it up to date, you still need to db:schema:load to avoid the ‘abort if pending migrations’ thing: rake db:schema:load ; rake test
If your db/schema.rb might be out of date, rake db:schema:load db:migrate ; rake test
If you’re a glutton for punishment: rake db:migrate test