RSpec Style Guide

Test Organization

• Use describe blocks to wrap a set of tests against one functionality, such as tests for a single method.
• Use context blocks to wrap a set of tests against one functionality in the same state.
• Prefer multiple it blocks, each with one expect:

  describe '#my_cool_method' do
    context 'when foo is bar' do
      before { subject.foo = 'bar' }
  
      it 'returns true' do
        expect(subject.my_cool_method).to eq(true)
      end
  
      it 'increases count of thing' do
        expect { subject.my_cool_method }.to change(Thing, :count).by(1)
      end
    end
  
    context 'when foo is not bar' do
      before { subject.foo = 'other value' }
  
      it 'returns false' do
        expect(subject.my_cool_method).to eq(false)
      end
  
      it 'does not change count of thing' do
        expect { subject.my_cool_method }.to_not change(Thing, :count)
      end
    end
  end

• If you find yourself naming a test "... if some condition" or "when some condition, ...", that's a hint you should use a context block.
• Use factories instead of fixtures. Create only the data you need for testing the condition.
• Name tests in third-person present tense. Do not use "should":

  # BAD
  it 'should eat the bear' do

  # GOOD
  it 'eats the bear' do

Make Use of RSpec Features

• If multiple tests are checking a property of the same thing, DRY them up with subject:

  # BAD
  it 'includes location' do
    expect(assigns('message')).to match(/it was born in Belville/)
  end
  
  it 'sets creator' do
    expect(assigns('message').creator).to match(/Topolino/)
  end

  # GOOD
  describe '@message' do
    subject { assigns('message') }
  
    it 'includes location' do
      expect(subject).to match(/it was born in Belville/)
    end
  
    it 'sets creator' do
      expect(subject.creator).to match(/Topolino/)
    end
  end

• Use let(:variable)/let!(:variable) instead of before { @variable = ... }.
  • Use let when you only need the variable initialized when it is first referenced.
  • Use let! when you need the variable initialized when the containing block is initialized. Example: to create records before testing an #index Rails action that lists records.
• Use shared examples to DRY up duplicate tests for the same behavior from different things, e.g., model and controller ActiveSupport::Concerns used in multiple classes.

Test Coverage

• Test both negative and positive outcomes, e.g., don't just test that the action responds with 200 OK when given perfect input.
  • What happens when the resource is not found?
  • What happens when the record fails to save?
  • What happens if the user does not have permission?

Style

• Single blank line between it, describe, and context blocks.
• Put let, before, and after blocks before it blocks.
• No blank lines between let, before, after, and subject blocks.
• Single blank line between let/before/after/subject and it blocks:

  # BAD
  before { Foo.bar = true }
  
  after { Foo.bar = false }
  it 'does something' do
    ...
  end
  it 'does something else' do
    ...
  end
  let(:var) { create(:var) }
  
  subject { var.fiddly_bits }

  # GOOD
  before { Foo.bar = true }
  let(:var) { create(:var) }
  after { Foo.bar = false }
  subject { var.fiddly_bits }
  
  it 'does something' do
    ...
  end
  
  it 'does something else' do
    ...
  end

• Use single-line blocks with { } when the let/before/after/subject definition will fit within 80 characters. Otherwise, use multi-line blocks with do end.
• If the it block has a description or goes over 80 characters, use do end on multiple lines. Otherwise, use { }:

  # BAD
  it 'returns true' { expect(subject.foo).to eq(true) }
  
  it do
    is_expected.to respond_with(200)
  end

  # GOOD
  it 'returns true' do
    expect(subject.foo).to eq(true)
  end
  
  it { is_expected.to respond_with(200) }

• Use parentheses around parameters to nested method calls. The outer-most method's parentheses should be omitted:

  # BAD
  it { is_expected.to respond_with 200 }
  it { is_expected.to(respond_with 200) }
  it { is_expected.to(respond_with(200)) }

  # GOOD
  it { is_expected.to respond_with(200) }

Related:

• Ruby Style Guide
• Better Specs