I'm trying to create a rake task for a Rails 4.0.2 (Ruby 2.2.3) project that creates the test database along with seeding, then runs the test suite, and finally cleanups afterwards by dropping the test database. Here's a simple example below:
task better_test: :environment do
Rake::Task["test:setup"].execute
Rake::Task["test"].execute
Rake::Task["test:cleanup"].execute
end
The task above does invoke the test:setup rake task (create/seed the test database), then invokes the test rake task, and finally invokes the test:cleanup rake task. The problem however is that the last test:cleanup is invoked before the test rake task is finished running. Is there anyway to invoke the cleanup rake task after the previous tasks are complete?
Here's the output from running the task with trace:
$ RAILS_ENV=test be rake better_test --trace
/usr/local/rvm/gems/ruby-2.2.3/gems/activesupport-4.0.2/lib/active_support/values/time_zone.rb:282: warning: circular argument reference - now
/usr/local/rvm/gems/ruby-2.2.3/gems/honeybadger-1.16.3/lib/honeybadger/rack/user_feedback.rb:51: warning: circular argument reference - action
** Invoke better_test (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute better_test
** Execute test:setup
Creating test database.
** Execute db:test:setup
** Execute db:test:create
** Execute db:create
** Execute db:test:load
** Execute db:schema:load
** Execute db:test_project:setup
** Execute db:test_project:create
** Invoke db:create (first_time)
** Invoke environment
** Execute db:create
** Execute db:test_project:migrate:down
** Execute db:test_project:migrate:up
** Execute db:test_project:seed
** Execute test
** Invoke test:run (first_time)
** 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
** Invoke db:migrate:load (first_time)
** Invoke environment
** Execute db:migrate:load
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Execute db:drop
** Execute db:create
** Execute db:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
** Execute test:prepare
** Execute test:units
** Invoke test:functionals (first_time)
** Invoke test:prepare
** Execute test:functionals
** Invoke test:integration (first_time)
** Invoke test:prepare
** Execute test:integration
** Execute test:run
** Invoke test:decorators (first_time)
** Invoke test:prepare
** Execute test:decorators
** Execute test:cleanup
** Execute db:test:drop
** Execute db:drop
** Execute db:test_project:drop
** Invoke db:drop (first_time)
** Invoke environment
** Execute db:drop
Run options: --seed 19360
# Running tests:
EE....
Finished tests in 0.037493s, 160.0278 tests/s, 106.6852 assertions/s.
As you can see the tasks are invoked in order but the cleanup task is executed before the tests have completed. Any ideas to address this?
As it turns out, this was less to do with rake and more to do with the way Minitest executes its tests. I mentioned in the question it appeared that the rake tasks were being invoked in the correct order but the tests were executed later for some reason. The reason is because Minitest utilizes the ruby Kernel method at_exit for execution of the tests. The test files are read in at the time the rake test was invoked but all tests are executed at the end of the ruby program, even after my subsequent rake tasks. Here's a blog article that explains the issue in more detail: http://blog.arkency.com/2013/06/are-we-abusing-at-exit/.
Try to use the rake standard syntax for calling multiple tasks:
task better_test: ["test:setup", "test", "test:cleanup"]
Maybe this will resolve you problem.
Also, it seems that Rake actually builds the list of all tasks it should run before executing them, and run each one only once. For example:
task :a
task :b
task :c
task better_test: ["a", "b", "c", "b"]
results in:
$ rake better_test -t
** Invoke better_test (first_time)
** Invoke a (first_time)
** Execute a
** Invoke b (first_time)
** Execute b
** Invoke c (first_time)
** Execute c
** Execute better_test
As you see, the task b is run only once (the first one). I believe that your test:setup or test somehow depend on test:cleanup task. So it is called earlier than expected.
Rake::Task["test"].enhance do
Rake::Task["test:cleanup"].invoke
end
Related
I've been trying to set up a test db, but when trying to create, I keep coming across an error that I can't seem to get past when trying to populate the db.
When I execute:
bundle exec rake db:create db:migrate db:test:prepare --trace
create and migrate seem to run without errors when run separately, but test:prepare seems to throw the error.
The error starts with:
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:abort_if_pending_migrations
** Invoke environment
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:test:purge
** Execute db:test:load
** Invoke db:test:load_schema (first_time)
** Invoke db:test:purge
** Execute db:test:load_schema
** Invoke db:schema:load (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:load
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "capabilities" does not exist
LINE 5:
I've looked up, and tried a lot of the results shown on google, but none seem to help. New to this, so I'm completely stumped at this stage.
UPDATE:
I should mention that when doing:
rake db:create RAILS_ENV=test
->payments_test already exists
rake db:migrate RAILS_ENV=test
->rake aborted!
NoMethodError: undefined method `mq' for #<Rails::Application::Configuration:0x0000000508acf0> blah blah blah
Ruby rake db:seed aborting due to ** Execute db:abort_if_pending_migrations, but I think all the migrations were successful.
Here's the last portion of the output when I run rake db:migrate --trace
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
I assume that mean it was successful (I didn't see any aborts)?
Then when I run rake db:seed --trace I get (in summary):
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
loading plugins
(the plugins load with no errors) then:
** Execute db:abort_if_pending_migrations
does this mean the migration and the seed worked properly or not?
Thank you for your time & input!
If it didn't abort, it succeeded. Take a look at the code:
# desc "Raises an error if there are pending migrations"
task :abort_if_pending_migrations => :environment do
pending_migrations = ActiveRecord::Migrator.open(ActiveRecord::Migrator.migrations_paths).pending_migrations
if pending_migrations.any?
puts "You have #{pending_migrations.size} pending #{pending_migrations.size > 1 ? 'migrations:' : 'migration:'}"
pending_migrations.each do |pending_migration|
puts ' %4d %s' % [pending_migration.version, pending_migration.name]
end
abort %{Run `rake db:migrate` to update your database then try again.}
end
end
It literally does nothing if there aren't any pending migrations.
I've recently extracted a module to a Rails::Engine gem that contains a "dummy application" for running the tests on. rake spec now behaves differently, and is causing some specs to fail.
First, running rake spec --trace in the gem directory no longer causes this long invocation chain:
** Invoke spec (first_time)
** Invoke test:prepare (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:test:purge
** Execute db:test:load
** Invoke db:test:load_schema (first_time)
** Invoke db:test:purge
** Execute db:test:load_schema
** Invoke db:schema:load (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:load
** Execute test:prepare
** Execute spec
Instead just calling:
** Invoke spec (first_time)
** Execute spec
I don't see any code in RSpec::Core::RakeTask that does DB initialization, so this must be a Rails function added by the Rakefile in a Rails root directory.
I considered dealing with that by adding this:
task :my_spec do
ENV['RAILS_ENV'] = 'test'
Rake::Task['db:drop'].invoke
Rake::Task['db:create'].invoke
ENV['SCHEMA'] = '/Users/me/sandbox/my_app/db/schema.rb'
Rake::Task['db:schema:load'].invoke
Rake::Task['spec'].invoke
end
But none of these tasks are loaded by the Rakefile in the gem's root.
How can I get rake spec to initialize the test DB from this directory?
Second, rspec is no longer clearing the DB in between tests, so tests that relied on a pristine DB state are now failing. Perhaps this means I'm writing my tests wrong, but I have considered the "blank slate" idea for tests to be a helpful one when understand test output.
How can I get rake spec to clear the DB in between tests as it does for a normal Rails app?
I am using FactoryGirl in my rails application instead of Fixtures.
When i try to use factory girl in my test and create some test data, it shows like
PG:Error relation "users" doesn't exists (i have a model named User)
But when i run rake db:test:clone, and then run the test, the test is passed. The rake db:test:clone command clones all the table structure from development db to test db, and this fixes the issue.
But is there any way for me to not to run rake db:test:clone when using FactoryGirl?
or what am i missing?
Update :
I found out one other thing, i have another application which uses Rspec and FactoryGirl. In that application below are executed when running rake spec --trace command
** Invoke spec (first_time)
** Invoke db:test:clone_structure (first_time)
** Invoke db:structure:dump (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:structure:dump
** Invoke db:test:load_structure (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:test:purge
** Execute db:test:load_structure
** Invoke db:structure:load (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:structure:load
But in any of the new application i see the below executed when running rake spec --trace
** Invoke spec (first_time)
** Invoke noop (first_time)
** Execute noop
** Execute spec
Please suggest what am i missing?
regards
Balan
Every time you run a db:migrate, run a db:test:prepare as well, so the database changes are mirrored on your test database as well.
I found the solution, we need to create a rake task customrake.rake under /lib/tasks
and add the line task :spec => 'db:test:prepare', this will make sure rake db:test:prepare is executed before running Specs.
I am running the following comand on my mac os x shell:
RAILS_ENV=test rake spec --trace
** Invoke spec (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:clone_structure (first_time)
** Invoke db:structure:dump (first_time)
** Invoke environment
** Execute db:structure:dump
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:clone_structure
** Execute spec
This command stops here for more than 5 minutes before continuing, so I don't know what is happening to cause this big big delay.
Any ideas on how can I find what is slowing down "Execute spec" ?
Thanks