Before, I added code to a file called config/initializers/remote_publishers.rb which set up a connection to RabbitMQ using the Bunny gem on server startup.
However, this is now also executed when running rails c, rails g model SomeModel foo:integer, rails db:migrate etc.
For this app, the RabbitMQ-connection only makes sense when rails is started using rails s(erver).
What is the proper way to conditionally execute this code? Is there a way to see if Rails is starting as server, or only as task-runner?
What web server are you using? On Puma, for example, you can use
on_worker_boot do
# Establish RabbitMQ connection
end
Another possibility might be to check if defined?(Rails::Server) in your initializer: this should only be true when running in the context of the web server.
I am trying to set up an acceptance test for an ember application that is using ember-cli-mirage
The doc says that server is supposed to be a global if you are in an acceptance test, but that is not working for me.
You can see the test/code here https://github.com/chrisortman/ember-cms-frontend/blob/master/tests/acceptance/consent-document-test.js#L7
I managed to make it start working.
I had to qualify my usage of server with window.server
https://github.com/chrisortman/ember-cms-frontend/commit/548189a18e472402def2b69881219e7c2519e0e5
EDIT
It works when I run the tests in browser with the /tests url, but not when using ember test or ember test --server
EDIT2
Seems due to a bug, but if you specify something for your host values it works
https://github.com/chrisortman/ember-cms-frontend/commit/745e28c3feafeee8b5f7f0faa7a554b0a364fd52
With RSpec, I'm trying to test a Rails program that calls an external python script. When running the spec, RSpec has access to the test database rails_program_test. However, the python script cannot access the database rails_program_test.
Furthermore, while running rails console test in a separate terminal, queries show no records in the test database, even though the spec reports that records do exist. Finally, when I switch the RAILS_ENV to development, the python script has access to the rails_program_development database. Is there a way to access the test database outside of the spec?
This may be because the Rails app is using transactional fixtures. They are rolled back at the end of each test, so are never visible to external processes.
You might want to look at the DatabaseCleaner gem for a non-transactional approach, but your use case sounds very unusual.
I'm using rufus-scheduler for handling cron jobs for a Rails 3.2.x app. The root worker.rb is being fired off by foreman (actually upstart on this particular server) and therefore when it starts off it does not have the Rails context in which to operate. Obviously when I attempt to call logger or Rails.logger it will fail each time.
I'm using log4r as a replacement for the default Rails Logger, which is quite nice, but I am wondering what the proper solution for this problem would be:
1) Do I need to give the script the Rails context at startup (it is simply running rake tasks right now so it ends up getting the Rails environment when the worker script hands off to the rake task and I fear giving the script the Rails env before running the timed task would be overkill since it takes so long to fire up the env)? or
2) Should I just set up log4r as one would do in a non-Rails Ruby script that simply reads in the same log4r.yml config that the Rails app is using and therefore participate in the same log structure?
3) Or some other option I'm not thinking of?
Additionally, I would appreciate either an example or the steps that I should consider with the recommended implementation.
For reference, I followed "How to configure Log4r with Rails 3.0.x?" and I think this could be helpful when integrated with the above: "Properly using Log4r in Ruby Application?"
I think this might be what you're looking for..
Use this within the worker itself, and create a custom named log file
require 'log4r'
logger = Log4r::Logger.new('test')
logger.outputters << Log4r::Outputter.stdout
logger.outputters << Log4r::FileOutputter.new('logtest', :filename => 'logtest.log')
logger.info('started script')
## You're actual worker methods go here
logger.info('finishing')
Whenever I run rspec tests for my Rails application it takes forever and a day of overhead before it actually starts running tests. Why is rspec so slow? Is there a way to speed up Rails' initial load or single out the part of my Rails app I need (e.g. ActiveRecord stuff only) so it doesn't load absolutely everything to run a few tests?
I definitely suggest checking out spork.
http://spork.rubyforge.org/
The railstutorial specifically addresses this, and gives a workaround to get spork running nicely in rails 3.0 (as of this moment, spork is not rails 3 ready out of the box). Of course, if you're not on rails 3.0, then you should be good to go.
The part of the tutorial showing how to get spork running in rails 3.0
http://railstutorial.org/chapters/static-pages#sec:spork
Checking when spork is rails 3.0 ready
http://www.railsplugins.org/plugins/440-spork
You should be able to to speed up your script/spec calls by running script/spec_server in a separate terminal window, then adding the additional -X parameter to your spec calls.
Why is rspec so slow? because it loads all the environement, loads fixtures and all that jazz.
Is there a way to speed up Rails' initial load you could try using mocks instead of relying on the database, this is actually correct for unit testing and will definitly speed up your unit tests. Additionnaly using the spec server as mentionned by #Scott Matthewman can help, same with the autotest from zentest mentionned by #Marc-Andre Lafortune
Is there a way to single out the part of my Rails app I need (e.g. ActiveRecord stuff only) so it doesn't load absolutely everything to run a few tests? what about this
rake test:recent
I am not sure how the rspec task integrate with this but you could definitely use the test:recent task as a template to do the same with rspec tests if the.
rake test:rspec:recent
doesn't exist yet
because it loads all the environement, loads fixtures and all that jazz.
The real culprit is if you run it using rake spec, it runs the db:test:prepare task.
This task drops your entire test database and re-creates it from scratch. This seems ridiculous to me, but that's what it does (the same thing happens when you run rake:test:units etc).
You can easily work around this using the spec application which rspec installs as part of the rspec gem.
Like this:
cd railsapp
spec spec # run all specs without rebuilding the whole damn database
spec spec/models # run model specs only
cd spec
spec controllers/user* # run specs for controllers that start with user
I think the "zen" experience you're looking for is to run spec_server and autospec in the background, with the result being near-instant tests when you save a file.
However, I'm having problems getting these two programs to communicate.
I found an explanation here:
I've noticed that autotest doesn't send commands to the spec_server.
Instead it reloads the entire Rails environment and your application's
plugins everytime it executes. This causes autotest to run
significantly slower than script server, because when you run the
script/spec command the specs are sent to the spec_server which
already has your Rails environment fired up and ready to go. If you
happen to install a new plugin or something like that, then you'll
have to restart the spec_server.
But, how do we fix this issue? I'm guessing it would involve downloading ZenTest and changing code for the autotest program, but don't have time to try it out right now.
Are you running this over Rails? If so, it's not RSpec's initialization that's slow, it's Rails'. Rails has to initialize the entire codebase and yours before running the specs. Well, it doesn't have to, but it does. RSpec runs pretty fast for me under my small non-rails projects.
Running tests can be really slow because the whole rails environment has to load (try script/console) and only then can all tests run. You should use autotest which keeps the environment loaded and will check which files you edit. When you edit and save a file, only the tests that depend on these will run automatically and quickly.
If you're using a Mac I recommend using Rspactor over autotest as it uses a lot fewer resources for polling changed files than autotest. There is both a full Cocoa version
RSpactor.app
or the gem version that I maintain at Github
sudo gem install pelle-rspactor
While these don't speed up individual rspec tests, they feel much faster as they auto run the affected spec's within a second of you hitting save.
As of rspec-rails-1.2.7, spec_server is deprecated in favor of the spork gem.
The main reason is that require takes forever on windows, for some reason.
Tips for speedup:
spork now works with windows, I believe.
You can try "faster_require" which caches locations:
http://github.com/rdp/faster_require
GL.
-rp
If you are on a Windows environment then there is probably little you can do as Rails seems to startup really slowly under Windows. I had the same experience on Windows and had to move my setup to a Linux VM to make it really zippy (I was also using autotest).