When you’re doing behaviour driven development the general idea is that you write your test cases, then you write code until the test cases pass. This means you’re running your test cases all the time. In fact, with any automated testing at all, you’re going to find yourself getting errors in your test cases then running them over and over.
Auto testing involves a set of code that watches the changes you’re making to your project, each time you save something it runs the associated tests. This aims to make sure that your changes are generally not breaking stuff.
With Ruby on Rails, the tool I’ve chosen is guard. Guard has plugins for lots of different testing tools, and lots of settings and options. For this instance, we’re going to use it with rspec.
There is a good railscast that tells us how to use it: http://railscasts.com/episodes/264-guard?view=asciicast
To install it, we first add it to our Gemfile:
gem "guard", :group => :development gem "guard-rspec", :group => :development
Then we install
Then we configure our guardfile, which tells guard what things to watch:
guard init rspec
This creates a Guardfile in the root of our project directory. I can sort of see that it’s pattern matching files that might have changed, and telling it which rspec to call when that happens. The railscast explains a bit about that, I haven’t done any work to change the settings. For arguments sake I might change the settings for a file like “ability.rb” which potentially impacts every test case, to run everything. For now, I’ll just manually run them all if I need to.
I’ve modified the Guardfile so it doesn’t run all specs on startup, and doesn’t automatically run all specs as soon as you get a pass (because we have lots of specs and they’re slow). To do this, edit the existing guard ‘rspec’ to look like:
guard 'rspec', :all_after_pass => false, :all_on_start => false do
Then, you can run guard
Whenever you change a file it will run the associated spec. You can also run other commands, for instance “all” will run all your specs.
What you’ll notice pretty quickly is that there’s a long startup time on each test case, then the tests themselves run reasonably quickly (particularly if you’ve finally sorted your IO problems here). Spork is a tool that keeps a rails instance running in the background, so whenever you want to run a test it just uses that existing running rails, rather than starting up a whole new one. This makes testing run faster with less overhead.
My integration of guard and spork is based on the following sources:
First, add spork to your Gemfile
gem "spork", :group => [:development, :test] bundle install
Run the bootstrap to put the right commands into your spec_helper:
Open spec/spec_helper.rb to setup spork some more. You can read the instructions in the file, basically what you want to do is to split your spec_helper into two sets of code – some that you put into prefork, which means it gets done once at startup – and some that you need to run before every test. In general, try putting everything into prefork, and see if it works. It did for me.
Run a spork server in a terminal:
Then run guard in another terminal:
Now go to town. Changes you make to files should be automatically tested.