I'm running guard in my Rails app and the test suite (minutest) has recently stopped working properly.
If I'm lucky, it'll run all of the tests once, maybe twice. After that, it takes so long to respond to even one small test file being changed that using the gem becomes futile.
When following top
while the tests run, I can see there's a ruby process that's taking up over 100% of the CPU constantly. Even once all tests are run and I haven't made any changes to the file.
The ruby process is:
/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 screenshot attached.
Ruby 2.0.0-p247
Here's 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:
SOLUTION:
I resolved it, by adding an '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
It seems, that this is best practice for guard/rspec/rails.
Guard 'ignore' infos: https://github.com/guard/guard/wiki/Guardfile-DSL---Configuring-Guard#ignore
MY PROBLEM
I was experiencing something quite similar on my mac os x 10.9 machine using:
after starting guard to run my rspec tests, the guard process jumped to 100% load on one core while "idling", it stayed like this long enough for me to qualify as "forever". :)
I tried to run guard
No change.
My colleague works on linux on the same project, so he uses rb-inotify instead of rb-fsevent. He's got no load while idling (as you would expect for mac os too...).
As written above, my solution was to add an 'ignore' statement to my Guardfile.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With