This is article four of my Introduction to Rails series. You can find the previous article under the title Models, Views, Controllers and Routing.

Have you, my honored reader, ever used automated testing tools? Would you be interested in trading those hours you spend clicking the same buttons over and over again before every release for a script that runs in the background, live, while you work? In my years of coding and reading about PHP I’d never heard of such tools. Apparently they do exist, but they don’t seem to be prevalent in the community. With Rails it’s the opposite. Tests are everywhere.

Did you read the Ruby on Rails Tutorial yet? What about the Getting Started With Rails guide? The former includes testing starting in chapter three, while the latter links to a dedicated testing tutorial. I chose these two because they are the first linked on the official website and the first Google result for “Ruby on Rails tutorial”, respectively. My favorite RoR documentation source, RailsCasts, deals with testing extensively. One can’t help but at least notice the concept of automated testing when learning Rails these days.

So what exactly does automated testing entail? It’s fairly simple. Write some Ruby code which makes assertions about the state of the system. Then, execute the code within our Rails environment. You could do this manually, but I’ve found a few tools to help you out with this process.

RSpec

One thing Ruby is well known for is the power to create Domain Specific Languages (DSL). RSpec is a tool (and Ruby gem of the same name) which creates a DSL for testing thought by many (including myself) to be very readable and intuitive. It allows you to write in a fashion such as “User.email should_not be_blank” or “should change(User, :count).by(1)”. This isn’t essential, but it can be much nicer to work with.

Capybara

Suppose we want to test something a little more complex than models and controllers. We want to take a step back and test the entire system as it appears to a user. Enter Capybara.

The capybara is the largest living member of the rodent family. They eat grasses, fruit and their own feces. They– wait, this is the wrong capybara.

Capybara is a testing tool which allows your scripts access to interact with the external interface of your application as if they were a user. You can tell it to do things like “visit login_path”, “fill_in ‘Username’, with: user.username”, “fill_in ‘Password’, with: user.password” and then “click_button ‘Login’”. This allows end to end testing of functionality by simulating real use of the system. Unfortunately, Capybara doesn’t support execution of JavaScript. That’s ok though, who needs JS anyway?

Poltergeist

Actually, it turns out I need JS support in my tests. My own CRM software is heavily JS based (using AngularJS as a front end library). Capybara supports multiple JS testing tools such as Selenium, which opens a visible browser, or PhantomJS, which is a headless (read: invisible) browser with JS support. If you like to watch your tests run I suppose the former is the best choice for you, but I like to have my tests run in the background. I suggest installing the Poltergeist gem which links Capybara tests to the PhantomJS application.

Guarding the Spork

Now that your tests can once again run quietly in the background the question arises: Why aren’t they running quietly in the background? They still require manual intervention. That’s bad for my “lazy factor”. One of my great joys in programming has always been the ability to automate menial tasks. I guess that’s why automated testing in general roped me in so quickly. So what can we do about this problem?

There are two other gems for Rails which can help in this situation. Spork is a tool which speeds up test launch time by keeping a server running in the background. This may not seem like a big deal when you only run tests once in a while but we’re going to be running tests constantly with Guard-Rails.

No, not that kind. Guard monitors your application files and re-runs associated tests when those files are updated. In essence, every time you hit the save hotkey (which I do constantly) it re-runs the tests. This can actually be distracting until you learn to ignore it when you know your tests should be failing during development. I find that hiding my Guard’s Yakuake console is enough to put it out of mind.

What’s left? At some point I’d like to get a physical light which can be programmatically changed from green to red to indicate passing or failing tests. Then I’d never even have to check the console!

From the very first moment I read about automated testing I knew I could never go back. It is my new way of life. I hope this post helped you experience the same elation I felt in learning. Stay tuned for the next part in the series this coming Monday. [Update: Object-Relational Mapping with ActiveRecord has been posted].