Another topic for which there is no shortage of Google results, but none that have really helped us to figure out why it takes upwards of three minutes for our tests to start. Finally reached my breaking point today and decided to track down what was behind the painful slowness of our test invocation.
The answer, for us, was the time it takes to purge and re-load the database when tests were starting. To figure this out, I simply ran
rake test --trace
And observed as we sat for two minutes on the db:schema:load. Ouch.
The good news is that, since we don’t use fixtures (chill runs down spine at the thought), there is really no need for us to purge our test DB every time we want to invoke tests. So, I decided to hack together a patch to allow tests to begin without the usual purge/load dog and pony show that goes with starting tests. If that’s the sort of thing that you’d be into, here’s the code you need to make it happen (in Rails 3, not sure how this might vary for Rails 2):
Rake::TaskManager.class_eval do
def remove_task(task_name)
@tasks.delete(task_name.to_s)
end
end
Rake.application.remove_task('db:test:load')
namespace :db do
namespace :test do
# Re-creating the DB every time we run tests sux...
task :load do
end
end
end
Basically, the first bit is to undefined the existing “db:test:load” method, and the last part redefines db:test:load to do nothing. Add this as a mixin in your config/initializers directory and you should be golden.
If you do want to re-create your test database on occasion, you can still do that by running
rake db:test:purge RAILS_ENV=test
rake db:schema:load RAILS_ENV=test
Chances are that the RAILS_ENV isn’t even necessary there, but I don’t really feel like testing whether or not it deletes my main database atm.
Using this, our test start time dropped from about 3 minutes to 10 seconds. And that’s change that we can believe in.