RSpec Runthrough March 2012

rspec_runthrough.md

Rspec

Philosophy

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

• Cheat Sheet, the whole thing compressed into 3 pages https://gist.github.com/1852758
• RSpec Documentation (sadly not complete)
• https://www.relishapp.com/rspec/rspec-core/docs
• Complete API http://rspec.info/
• Awesome Blogpost http://areyoufuckingcoding.me/2012/03/25/nothing-really-matters/
• 10 min presentation (slides) http://blog.bandzarewicz.com/slides/krug-the-perfect-rspec/#34
• Rspec Best Practices
  • http://thinkvitamin.com/code/ruby-on-rails/an-introduction-to-rspec/
  • http://bitfluxx.com/2011/05/23/some-rspec-tips-and-best-practices.html
  • http://kpumuk.info/ruby-on-rails/my-top-7-rspec-best-practices/
  • http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/
  • http://blog.carbonfive.com/2010/10/21/rspec-best-practices/

The Toolkit

RSpec

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

https://github.com/jnicklas/capybara Capybara provides some view testing for requests, also full browsers test with a headless webkit.

  within("#session") do
    fill_in 'Login', :with => 'user@example.com'
    fill_in 'Password', :with => 'password'
  end
  click_link 'Sign in'

Shoulda

https://github.com/thoughtbot/shoulda-matchers 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) }
end

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

Factory Girl

http://thinkvitamin.com/code/ruby-on-rails/an-introduction-to-rspec/ create objects on fly, makes testing with real objects much easier, replaces mocking, but it's a bit slow.

Guard

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

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.

put

binding.pry-remote

somewhere in your code, run it and start

pry-remote

.

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)