Create a gist now

Instantly share code, notes, and snippets.

RSpec Runthrough March 2012



The suite of tests is not there to satisfy the QA groups, it is not there to prove to other people that our code works. The suite of tests is there so that we can refactor. So that when we bring the code up to our screen then we're not afraid of it. @unclebobmartin

List of useful resources

The Toolkit


This is the basic DSL all our specs are written in. Provides expectations to set on a feature, and then to code to it.

Capybara Capybara provides some view testing for requests, also full browsers test with a headless webkit.

  within("#session") do
    fill_in 'Login', :with => ''
    fill_in 'Password', :with => 'password'
  click_link 'Sign in'

Shoulda A couple of matchers to test Rails / ActiveModel specific behaviour

describe Post do
  it { should belong_to(:user) }
  it { should have_many(:tags).through(:taggings) }

describe User do
  it { should have_many(:posts) }

Factory Girl create objects on fly, makes testing with real objects much easier, replaces mocking, but it's a bit slow.


bundle exec guard

Guard runs your spec in the background, it's sort-of smart and tries to run only the specs that are affected by your code changes.


Pry is an awesome IRB / Rails console replacement, that lets you dive into objects, manipulate it's code at runtime and does line-by-line debugging. It also offers hooks to be triggered by your rails server / specs.



somewhere in your code, run it and start



What we don't use (anymore)

  • Cucumber, we use RSpec for our Request / Integration / Acceptance tests as well.
  • Mocks, Mocha: Mocking let's you test only the features you are actually working on. However this has become very unpopular in the past year or two. People tended to mock so much, they weren't actually testing anything useful anymore.
  • Webrat, obsolete since Capybara
  • autotest(surpassed by guard)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment