Rails, Minitest and Guard - Why does rb-fsevent take up more than 100% of the processor?

Question

I work in my Rails application and the test suite (minutest) has recently stopped working properly.

If I'm lucky, he will run all the tests once, maybe twice. After that, it takes so much time to answer even one small test file, which changes, that using the gem becomes useless.

When executing top while testing, I see that there is a ruby ​​process that takes up more than 100% of the CPU constantly . Even after all the tests have been started, and I have not made any changes to the file.

Ruby process:

 /Users/Bodacious/.rvm/gems/ ruby-2.0.0-p247@MyApp /gems/rb-fsevent-0.9.3/bin/fsevent_watch --latency 0.1 /Users/Bodaiou/Clients/MyApp 

(process 31332 ) in the attached screenshot.

Ruby 2.0.0-p247

Here is my setup:

 # Gemfile (with irrelevant gems removed) gem 'rails', '4.0.0' group :test do gem 'launchy' gem "mocha", require: false gem 'database_cleaner' gem 'selenium-webdriver' gem 'capybara-webkit' # for headless javascript tests gem 'timecop' gem "minitest-focus" end group :development, :test do gem "minitest-rails" gem "minitest-rails-capybara" gem 'zeus' gem 'guard' gem 'guard-minitest' gem 'factory_girl_rails' end # Guardfile guard :minitest, all_on_start: false do # Rails 4 watch(%r{^app/(.+)\.rb}) { |m| "test/#{m[1]}_test.rb" } watch(%r{^app/controllers/application_controller\.rb}) { 'test/controllers' } watch(%r{^app/controllers/(.+)_controller\.rb}) { |m| "test/integration/#{m[1]}_test.rb" } watch(%r{^app/views/(.+)_mailer/.+}) { |m| "test/mailers/#{m[1]}_mailer_test.rb" } watch(%r{^lib/(.+)\.rb}) { |m| "test/lib/#{m[1]}_test.rb" } watch(%r{^test/.+_test\.rb}) watch(%r{^test/test_helper\.rb}) { 'test' } ignore(%r{^tmp/}) end # test_helper ENV["RAILS_ENV"] = "test" require File.expand_path("../../config/environment", __FILE__) require 'rails/test_help' require 'minitest/autorun' require 'minitest/pride' require "minitest/rails/capybara" require "mocha/setup" # Sidekiq https://github.com/mperham/sidekiq/wiki/Testing require 'sidekiq/testing' Sidekiq::Testing.fake! Dir[Rails.root.join('test', 'support', '*.rb')].each do |file| require file end class MiniTest::Spec include FactoryGirl::Syntax::Methods include AllTestHelper end class ActiveSupport::TestCase include FactoryGirl::Syntax::Methods include AllTestHelper end class Capybara::Rails::TestCase include Rails.application.routes.url_helpers include Capybara::DSL include Capybara::Assertions include IntegrationTestHelper # Called before each Feature spec before :each do end # Called after each Feature spec after :each do Capybara.reset_sessions! end end 

Gem Versions:

• minitest (4.7.5)
• minitest-capybara (0.5.0)
• minitest-focus (1.1.0)
• minitest-metadata (0.4.0)
• minitest-rails (0.9.2)
• minitest-rails-capybara (0.10.0)
• motive rails (0.1.2)
• mocha (0.14.0)
• guard (2.2.4)
• guard-minitest (2.1.2)
• rb-fsevent (0.9.3)

Answer 1

DECISION:

I resolved it by adding the 'ignore' statement to my Guardfile. For my rails 3 project, it looked like this (./Guardfile):

 ignore([%r{^bin/*}, %r{^config/*}, %r{^db/*}, %r{^lib/*}, %r{^log/*}, %r{^public/*}, %r{^tmp/*}]) guard 'rspec', cmd: 'spring rspec', all_after_pass: false, all_on_start: false, focus_on_failed: true do # Rails watch(%r{^spec/.+_spec\.rb$}) ... end 

This seems like best practice for guard / rspec / rails.

Protect “ignore” information: https://github.com/guard/guard#ignore

MY PROBLEM

I came across something very similar on my mac os x 10.9 machine using:

• spring (1.0.0)
• rb-fsevent (0.9.3)
• growl (1.0.3)
• rspec-core (2.14.7)
• rspec-wait (2.14.4)
• rspec-mocks (2.14.4)
• rspec (2.14.1)
• guard-rspec (4.2.0)
• listen (2.4.0)
• rspec-rails (2.14.0)
• rails (3.2.15)

after starting protection to run my rspec tests, the protection process jumped up to 100% of the load on one core, while it was idle, it remained the way it was long enough so that I could qualify as forever. :)

I tried to start the guard

• with forced poll
• without `watch 'instructions
• with spring
• without spring

Without changes.

My colleague is working on linux in the same project, so he uses rb-inotify instead of rb-fsevent. It did not boot at idle (as you would expect for mac os too).

As written above, my solution was to add the 'ignore' file to my Guard file.