I am using Specjour v0.4.1 for full test suite runs and preloading a rails app to run individual specs with Spork and Guard. Specjour uses multiple workers (usually 4) to run tests simultaneously.
How can I pass the preloaded application to each one of these workers? As specjour continues to load the application for each worker.
Note: rspec spec/models/example_spec.rb --drb is used to force rspec to use the preloaded application.
I've forked specjour and tried to push the --drb flag to each worker using several methods with no success. Any insight would appreciated. Thanks!
Note: hooks.rb configuration seems promising (mentioned in the README), however, documentation is extremely slim.
Related
I am using RSpec with RoR 4.1, if I run
bundle exec rspec spec/requests/citilink_request_spec.rb
or
bundle exec rspec spec
Then rspec will load the files correctly if it is the first execution, but at the second execution, it'll load the cached file. I can confirm this that the backtrace produced refer to the old point which I swapped with comment. It refers to a comment!
How can I disable this functionality, it shouldn't be de default setting IMHO.
It is not RSpec problem, but Sidekiq. Yah, I am using Sidekiq. And the Sidekiq part not loading again my code whenever it changes. So, I need to reload the Sidekiq and everything works as expected.
I should have mentioned that the code in question is working asynchronously in a worker executed by Sidekiq that is using Redis.
I have followed this tutorial on speeding up rspec with spork, and I am on a win7 x64 box with ruby 1.9.2 and rails 3.2.5. Everything is working, but test still execute slowly. Does spork simply not do much on windows because the OS doesn't support forking?
Is there anything else I can do to speed things up?
I also found this similar SO question, and watched the video by Corey Haines on fast testing. I enjoyed the video, but I can't help feeling that something is off when the state of our tools (slow tests due to rails startup time, in this case) dictates how we structure our code. If that slow startup time didn't exist, would there be any need for his methods? On the other hand, with tests taking 10-30 seconds to run, so many of the benefits of TDD are lost that I see his point of view as well.
In case it's relevant, here's the console output from spork as the rspec was executed a couple times:
$ bundle exec spork
Using RSpec
-- Starting to fill pool...
Wait until at least one slave is provided before running tests...
** CTRL+BREAK to stop Spork and kill all ruby slave processes **
Spork is ready and listening on 8989!
-- Rinda Ring Server listening for connections...
-- build slave 1...
Preloading Rails environment
-- build slave 2...
Preloading Rails environment
Loading Spork.prefork block...
Loading Spork.prefork block...
Running tests with args ["--color"]...
--> DRb magazine_slave_service: 1 provided...
--> DRb magazine_slave_service: 2 provided...
<-- take tuple(2); slave.run...
-- (2);run done
Done.
-- build slave 2...
Preloading Rails environment
Loading Spork.prefork block...
Running tests with args ["--color"]...
<-- take tuple(1); slave.run...
-- (1);run done
Done.
-- build slave 1...
Preloading Rails environment
Loading Spork.prefork block...
--> DRb magazine_slave_service: 2 provided...
The Code Shop is building an MRI Ruby optimized for Windows, you can find more about it on their Website or their Github Repo.
I also suggest you to watch this talk about developping rails apps on Windows
Try checking out http://railscasts.com/episodes/413-fast-tests. This shows a lot of different tools that can improve the speed of your test suite significantly!
Before, I was as patient as anybody else in running RSPEC tests using Windows! Doing rake(s) takes too much of my time and it wasn't really healthy anymore. Deliverables were some kind of delayed because the development in Windows was such a pain. And that's the truth. That's why I switched to Linux. But sometimes, there were still trouble(s) in using Linux (hassle installation of some stuffs and more). I just remained patient until I switched to MAC which is a lot better.
If you are really consistent in using Windows for ROR then running tests would be that slow if there are plenty of modules to test.
I'm kinda sure also that Selenium testing would be a disaster in Windows.
But, you may also try to add some other stuffs like using GUARD (for faster execution of test scripts) wherein you don't have to type rspec spec repeatedly.
See: https://github.com/guard/guard
For the spork, well I also encountered a bug about it (before)... wherein I'm testing some spec files using Linux and then it was so slow that I really hated using it.
And that's the reality.
Check out how I configured SPORK to work for rspec:
spec_helper.rb
See: https://github.com/xirukitepe/animelist/blob/master/spec/spec_helper.rb
I would use a linux VM for this kind of thing...
The biggest increase in test speed I've managed to get with RSpec has been to ensure it never hits the database unless it absolutely has to.
We have a suite of Selenium tests. I'd like to use SimpleCov to coverage the server-side coverage of those tests. First off, is this a common approach? I haven't been able to find anything on SimpleCov/Selenium. Maybe SimpleCov is usually used for unit/functional tests instead of integration?
Current Selenium setup requires booting up a rails server, than having a suite of Selenium tests hit it. I'd need SimpleCov to run on the rails server, then quit after the suite is done.
Any help greatly appreciated!
simplecov author here. Whenever you launch SimpleCov, it applies the coverage analysis to the currently running process. Therefore, you would need to launch SimpleCov inside your Rails server process. I would recommend adding the SimpleCov setup as a conditional to your Rails app's config/boot.rb (at the very top), like so:
# config/boot.rb
if ENV["SELENIUM"]
require 'simplecov'
SimpleCov.start 'rails'
end
Before booting your Rails test server, set that environment variable. You should now receive a coverage report once the test server is shut down. Please check out the config options if you want to move it to another directory so it does not interfere with your regular (unit/functional) coverage report.
I am not sure that boot.rb is the right place though. The fact is that SimpleCov needs to be loaded before anything else in your app is required or it won't be able to track coverage for those files. You might need to experiment or have a look into the rails boot process to find that place, but as the Bundler setup is part of boot.rb (if I remember correctly...), putting the mentioned config above the Bundler.setup should be fine.
Basically, with a similar setup you can even get code coverage for your local manual browser-based testing by launching simplecov in your server process, clicking around and exiting the server, if for example you want to know what part of your application a certain action really touches.
I would like my development environment for Rails to automatically start redis and resque (and potentially in other projects, mongod, mysql-server etc.) for me, in the following cases:
When starting up the development server rails server.
Additionally, it would be nice if the following cases detect already running services, and, if not running start them up too:
Rake rspec, rspec /spec, when running tests.
When starting up a rails console.
When shutting down the rails server, the started child-services should be shut down too.
What is the correct place for such additional startup scripts?
And how to avoid them being started in production too (where I run everything trough /etc/init.d services)?
A lot of these built-in tasks are available as rake tasks already.
You can create a master rake task that does it all.
For example, with resque, you get "rake resque:start" "rake resque:scheduler:start", etc.
You can create a generic "start" task that depends on the rest. Similarly, a "stop" task would shut everything down.
So you would do:
rake start # starts all associated processes
rake stop # stops them all
This is also very use to use from Capistrano, when you end up deploying your code somewhere else. Rake tasks are very easy to call from Capistrano.
I think it's really better to do that in some external script. Do it in your rails server command can be really annoying to anyone to try your code.
By example, in one year, a nez developper come to your project. He can be desoriented if your rails server commande launch a such of other application in background.
In same idea, if you do that you need maintain your code in your rails env. Can be a little tricky. Maintain an independant script can be more usefull.
You can add your script in script directory. That be a good pratice. But not when you launch a command with a manual who do not that.
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).