Update (10/15/2012): This isn’t how I’m doing it now. See this aside for my current workflow.

(That Latour article is in a half-finished limbo state, but I’ll get around to posting it eventually).

I wrote in a recent post about how easy it is to configure Autotest these days. And Autotest has been an essential part of my toolset as I’ve developed my humble todo app, Method Todo. I’ve only been using it to run my Rspec stories (and not Cucumber features, since they take too long). Now that I’m adding another testing discipline, testing javascript code with Jasmine, I find that there’s an even simpler way to run all your tests — specs, features and Jasmine specs — continuously and in the background.

I decided to use Guard because I couldn’t get Jasmine to access the necessary asset pipeline files to run Javascript tests, I guess because those files needed to be precompiled. Once I started using guard-rails-assets I decided to try out the other plugins for Rails, Rspec and Cucumber. It seems to all just work and the ecosystem of plugins seems like it will provide quick solutions to obscure problems down the road.

So after deleting the Autotest dependencies out of my Gemfile, I have:

# other sections for rails, rspec, spork, etc., etc. 

group :guard do                                                           
  gem 'guard'                                                                   
  gem 'guard-rails'                                                             
  gem 'guard-spork'                                                             
  gem 'guard-rspec'                                                             
  gem 'guard-cucumber'                                                          
  gem 'guard-rails-assets'                                                      
  gem 'guard-jasmine-headless-webkit'                                           
end

Then I run

bundle exec guard init

to create the Guardfile with sensible defaults.

Then running

bundle exec guard

will start running all of these tasks together. The default for the Cucumber guard task seems to only watch changes in feature files before re-running Cucumber, so I’ll leave this guard in as long as it doesn’t delay the re-running of specs. A bonus is that the Rails guard starts up the development server and restarts it when you change major configuration files.

Update (7/25/2012):

I found that guard-rails-assets didn’t seem to be necessary for jquery-guard-headless-webkit to process assets. I removed it to see if it would fix a strange issue with the bootstrap-modal library that only occurs in development mode (it didn’t, but it also didn’t seem to break anything).

I also found that guard-rails was loading into the test environment when paired up with the other testing guard tasks. Changing the initial generated line to

guard 'rails', :environment => 'development' do                                 
  watch('Gemfile.lock')                                                         
  watch(%r{^(config|lib)/.*})                                                   
end

seemed to fix things.