So, whenever I run "rake spec" in my application directory, I see this:
admin#nurvus:~/workspace/spec $ rake spec
(in /Users/admin/workspace/)
DEPRECATION WARNING: Rake tasks in vendor/plugins/abingo/tasks, vendor/plugins/delayed_job/tasks, vendor/plugins/funkytown/tasks, vendor/plugins/funkytown/tasks, vendor/plugins/git_helper/tasks, vendor/plugins/git_helper/tasks, and vendor/plugins/jrails/tasks are deprecated. Use lib/tasks instead. (called from /.rvm/gems/ruby-1.8.7-p299/gems/rails-2.3.8/lib/tasks/rails.rb:10)
** 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:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
** Execute spec
No server is running
Running specs locally:
DEPRECATION WARNING: require "activesupport" is deprecated and will be removed in Rails 3. Use require "active_support" instead. (called from /.rvm/gems/ruby-1.8.7-p299/gems/activesupport-2.3.8/lib/activesupport.rb:2)
DEPRECATION WARNING: require "activerecord" is deprecated and will be removed in Rails 3. Use require "active_record" instead. (called from /.rvm/gems/ruby-1.8.7-p299/gems/activerecord-2.3.8/lib/activerecord.rb:2)
Example disabled: should return the next ordered survey
Example disabled: should not redirect unsupported browser
admin#nurvus:~/workspace/spec $
There are over 2500 tests that just aren't getting run, but it's obviously parsing the files, since the disabled examples are being seen. Any top-level thoughts on this?
Related
I make an image-upload for a user profile using the activestorage gem built into rails, but it is not working, the intriguing part is that there are no errors, the migration just does not get created.
What is wrong here, any ideas on how I can fix this?
rails version - 6.0
I added require 'active_storage/engine' to the config/application.rb file already
And then ran rails active_storage:install
What is even more intriguing is that I get the same output without adding the require active_storage/engine to application.rb. And there are no errors
output
** Invoke active_storage:install (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute active_storage:install
** Invoke active_storage:install:migrations (first_time)
** Execute active_storage:install:migrations
** Invoke railties:install:migrations (first_time)
** Invoke db:load_config (first_time)
** Invoke environment
** Execute db:load_config
** Execute railties:install:migrations```
I expect the migration file to be created after this but it is not.
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
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.
The following is my environment:
OS X 10.5
Xcode 3.1.4
rvm 0.1.38
ruby 1.8.9-p399 (via rvm)
rails 2.3.8
I started getting this error when rake tries to run my tests:
bash$ rake
Virtual timer expired
bash$ # End of output!
And with tracing enabled:
bash$ rake --trace
** Invoke default (first_time)
** Invoke test (first_time)
** Execute test
** Invoke test:units (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:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
Virtual timer expired
bash$
It looks like there is an problem in ruby, rev23993 causes Virtual Timer Expired when forking, which in turn triggers the error inside the mysql gem.
The practical workaround seems to be to downgrade the mysql gem from 2.8.1
to version 2.7:
#environment.rb
config.gem 'mysql', :version => '2.7'