RSpec best practices and tips

After a year using RSpec, I’m happy to share “(My) RSpec Best Practices and Tips”. Let’s make your specs easier to maintain, less verbose, more structured and covering more cases!

Use shortcuts specify {}, it {} and subject {}

You think RSpec is verbose? In case your code doesn’t need any description, use a specify block!

it "should be valid" do
@user.should be_valid

can be replaced with

specify { @user.should be_valid }

RSpec will generate a nice description text for you when running this expectation. Even better, you can use the it block!

describe User do
it { should validate_presence_of :name }
it { should have_one :address }

In case the subject is the not the class described, just set it with the subject method:

subject { @user.address }
it { should be_valid }

Start context with ‘when’/’with’ and methods description with ‘#’

Have you ever get a failed test with an incomprehensible error message like:

User non confirmed confirm email wrong token should not be valid

Start your contexts with when and get nice messages like:

User when non confirmed when #confirm_email with wrong token should not be valid

Use RSpec matchers to get meaningful messages

In case of failure

specify { user.valid?.should == true }


'User should == true' FAILED
expected: true,
got: false (using ==)


specify { user.should be_valid }


'User should be valid' FAILED
expected valid? to return true, got false

Nice eh?

Only one expectation per it block

I often see specs where it blocks contain several expectations. This makes your tests harder to read and maintain.

So instead of that…

describe DemoMan do
it "should have expected attributes" do
demo_man =
demo_man.should respond_to :name
demo_man.should respond_to :gender
demo_man.should respond_to :age

… do this:

describe DemoMan do
before(:all) do
@demo_man =
subject { @demo_man }
it { should respond_to :name }
it { should respond_to :gender }
it { should respond_to :age }

(Over)use describe and context

Big specs can be a joy to play with as long as they are ordered and DRY. Use nested describe and context blocks as much as you can, each level adding its own specificity in the before block.
To check your specs are well organized, run them in ‘nested’ mode (spec spec/my_spec.rb -cf nested).
Using before(:each) in each context and describe blocks will help you set up the environment without repeating yourself. It also enables you to use it {} blocks.


describe User do
it "should save when name is not empty" do => 'Alex').save.should == true
it "should not save when name is empty" do == false
it "should not be valid when name is empty" do be_valid
it "should be valid when name is not empty" do => 'Alex').should be_valid
it "should give the user a flower when gender is W" do => 'W').present.should be_a Flower
it "should give the user a iMac when gender is M" do => 'M').present.should be_an IMac


describe User do
before { @user = }
subject { @user }
context "when name empty" do
it { should not be_valid }
specify { == false }
context "when name not empty" do
before { = 'Sam' }
it { should be_valid }
specify { == true }
describe :present do
subject { @user.present }
context "when user is a W" do
before { @user.gender = 'W' }
it { should be_a Flower }
context "when user is a M" do
before { @user.gender = 'M' }
it { should be_an IMac }

Test Valid, Edge and Invalid cases

This is called Boundary value analysis, it’s simple and it will help you to cover the most important cases. Just split-up method’s input or object’s attributes into valid and invalid partitions and test both of them and there boundaries. A method specification might look like that:

describe "#month_in_english(month_id)" do
context "when valid" do
it "should return 'January' for 1" # lower boundary
it "should return 'March' for 3"
it "should return 'December' for 12" # upper boundary
context "when invalid" do
it "should return nil for 0"
it "should return nil for 13"

I hope this will help you improve your specs. Let me know if I missed anything! :)

You could also be interested in (My) Cucumber best practices and tips or rspec-set a little gem that helps you speeding up your model specs.