I have an after_create_commit callback on my model, Foo, which looks like this:
after_create_commit { LogBroadcastJob.perform_later self }
I've reduced my perform method to return nil to simplify things.
When I create a Foo instance in an RSpec test with factory_girl, the test suite freezes. This only happens when I test models with that callback.
FactoryGirl.create :foo
When I Ctl+C out of my test suite it fails to kill the process. I have to find the process, which is still using my database (Postgresql), and kill it, which means that I don't see any errors on the command line. If I run my test suite again, it creates another process that I have to find and kill.
Does this sound familiar to anyone? How would I find useful errors here?
Maybe relevant: I upgraded from Rails 4.2 to 5.0.0.1 a while back.
This was a concurrency issue. Thanks to the resource provided in #coreyward's comment, I was able to clear this up by setting config/environments/test.rb to
config.eager_load = true
This differs from my config in config/environments/development.rb (and everything works in development), so I can't say I understand yet why it works. But I can now run all my tests with bundle exec guard or bundle exec rake spec.
Related
After upgrading from Rails 3 to Rails 4 the db:schema:load task is failing. I did some digging into it and found that after the upgrade when I run bundle exec rake db:schema:load the db/schema.rb file is being loaded twice. The first time it runs fine; then the second time through it fails due to a create_table force: true fails due to there being a dependency constraint on the table.
I've stripped out every additional rake task and enhance to try and rule out any of my code, but still this loads the schema.rb twice. It is always exactly twice as I am able to run it successfully on SQLite and see the same behavior there, but it runs to completion due to SQLite not enforcing the table constraints.
You are seeing it twice because in development Rails runs db tasks for test and development in the same run.
Please see the ActiveRecord::Tasks::Databasetasks file for details, especially methods #load_schema_current (this one because you were referring to it) and #each_current_configuration
You might check to be sure your Rakefile isn't loading tasks twice. When Rake registers a task with the same name as an existing task, it will run both in sequence rather than replace the old definition with the new one.
Here is my ruby spec_helper for rspec:
As you see I'm using database cleaner because I'm writing tests using the DB.
However, I get all this nonsense in my console output:
Is there a way to supress some of this output? Again remember, I'm not in RAils so I can't simply do:
config.logger.level = Logger::ERROR
Is there such thing as an embedded version of MongoDB suitable for use with RSpec, that can be started with a suite of tests?
In JavaLand, where I normally live when I'm not vacationing in the United States of Ruby, we are in the habit of starting portable embedded versions of database servers when we run tests, such as this Java-embeddable MongoDB.
Is there an equivalent for Ruby? Or do we always expect developers to have a local MongoDB running?
Currently, our replica set tests use a MongoConfig test tool to bring up RS members:
https://github.com/mongodb/mongo-ruby-driver/blob/1.x-stable/test/tools/mongo_config.rb
Check out this method for how to use it:
https://github.com/mongodb/mongo-ruby-driver/blob/1.x-stable/test/helpers/test_unit.rb#L38-L62
We don't use it for our non-replica set tests, but I don't see why you couldn't use it yourself. I also don't see anything about Rspec in particular that would make this difficult either.
I have a padrino server application with datamapper as ORM layer. I have a database migration, say:
migrate 1, :test do
up do
execute 'Some Query'
end
end
This migration is run using the command:
padrino rake dm:migrate -e <env>
Now my problem is that I need access to env in my query (not to choose schema or anything which datamapper does automatically, something very specific to the functionality). I tried debugging the migration to see if there is a variable which stores this value, but no luck. Is there a way?
As it turns out, since I am using Padrino, I can directly use Padrino.env inside up do..end or down do..end blocks:
migrate 1, :test do
up do
env = Padrino.env
execute "Some Query #{env}"
end
end
Although this is Padrino specific, but so is the concept of environment. I am sure something like this would work with other frameworks like Rails as well.
There's a bunch of questions out there similar to this one that talk about rails plugins as a solution - but I'm not using rails, read on for more
I have a Rakefile in a sinatra project which allows me to rake db:migrate. It'll do my migration perfectly, but I'd like to pass that a flag (or write a new rake task) which does the same thing, but outputs the SQL to STDOUT and doesn't commit the changes to the database. Does anyone know how to do this?
My first thought was to try ActiveRecord logging and see if I could get the SQL out at all, but that doesn't work! Any ideas?
namespace :db do
task :migrate_sql do
require 'logger'
ActiveRecord::Base.logger = Logger.new(STDOUT)
Rake::Task['db:migrate'].invoke
# This does the migration and doesn't output SQL - so no good!
end
end
I think there isn't any easy way to do it, for the following reasons:
up, down, and change are methods which execute other methods; there isn't a global migration query string that gets built and executed
neither the statements methods (add_column, etc) expose their statements as strings; as I understand, they are implemented as connection adapter methods, and for example the mysql adapter has a add_column_sql method, while the postgresql adapter does not, and its sql is a variable inside its add_column method
So, if you really need this functionality, I think your best option is to copy the sql from the log.