When to Use RSpec let vs before in Ruby Tests

By the end of this page, you will understand what let does in RSpec, how it differs from instance variables created in before blocks, and when each approach is the better choice. You will also learn about lazy evaluation, memoization, test readability, and common setup patterns used in real Ruby test suites.

let and before both help prepare data for RSpec examples, but they solve slightly different problems.

What before does

A before block runs setup code before each example. It is useful when you want to perform actions that must always happen before the test runs.

before do
  @user = User.new(name: "Ava")
end

Here, @user is an instance variable created before every example.

What let does

let defines a helper method whose value is computed only when you first use it inside an example. After that first call, the value is memoized, which means the same value is returned every time you call it again in that example.

let(:user) { User.new(name: "Ava") }

If an example never calls user, the block never runs.

The key differences

1. Execution timing

Think of before as preparing the whole kitchen before cooking.

• You take out ingredients.
• You heat the oven.
• You place tools on the counter.
• This happens every time, whether you use everything or not.

Think of let as a labeled container in the kitchen.

• You define that a container called user exists.
• You only open and use it if the recipe needs it.
• Once opened during that recipe, you keep reusing the same container.

So:

• before = do setup work ahead of time
• let = define a reusable value that is created only when needed

Basic before

RSpec.describe User do
  before do
    @user = User.new(name: "Ava")
  end

  it "has a name" do
    expect(@user.name).to eq("Ava")
  end
end

This runs the before block before the example, so @user is available inside the test.

Basic let

RSpec.describe User do
  let(:user) { User.new(name: "Ava") }

  it "has a name" do
    expect(user.name).to eq("Ava")
  end
end

This defines a method called user. The User.new(...) code runs only when is first called.

Consider this example:

RSpec.describe "let behavior" do
  let(:number) do
    puts "computing number"
    10 * 2
  end

  it "uses the value" do
    expect(number + number).to eq(40)
  end
end

What happens step by step

1. RSpec starts the example.

2. The let(:number) block has been defined, but it has not run yet.

3. The example executes number + number.

4. On the first call to number, RSpec runs the block:

   puts "computing number"
   10 * 2
   

5. The result 20 is stored for this example.

6. On the second call to number, RSpec returns the cached value .

When let is useful

Defining test data used by some examples

let(:user) { User.new(name: "Ava") }

Useful when:

• only some examples need the object
• the setup is just a value
• you want readable test inputs

Building related objects

let(:user) { create(:user) }
let(:post) { create(:post, user: user) }

This is common in Rails apps using factories.

Reusing computed values

let(:json) { JSON.parse(response.body) }

Good when parsing response data once and reusing it in several expectations.

When before is useful

Making requests

before do
  get "/api/profile"
end

The request is an action that should happen before assertions.

In real Ruby and Rails codebases, teams often follow a simple rule:

• Use let for values
• Use before for actions

Common patterns

1. Named test inputs with let

let(:params) { { email: "a@example.com", password: "secret" } }
let(:user) { create(:user) }

This makes specs read more like documentation.

2. Guarding setup cost

If object creation is expensive, let avoids unnecessary work in examples that do not use the object.

let(:report) { build_large_report(data) }

3. Request specs

let(:headers) { { "Authorization" => token } }
let(:token) { "abc123" }

before do
  get "/api/items", headers: headers
end

Here, defines data and performs the request.

1. Using before for simple values when let is clearer

Less clear

before do
  @user = User.new(name: "Ava")
end

Clearer

let(:user) { User.new(name: "Ava") }

If the setup is just defining a value, let is usually easier to read.

2. Forgetting that let is lazy

Broken expectation:

let(:user) { User.create!(name: "Ava") }

it "creates the user" do
  expect(User.count).to eq(1)
end

This may fail because user was never called.

Fix

let vs let!

Quick rules

• let(:name) { value } defines a memoized helper method.
• The let block runs only when first called in an example.
• The result is cached for the rest of that example.
• A new value is created for each example.
• before runs before every example.
• Use before for actions and side effects.
• Use let! when you want eager evaluation.

Common syntax

let(:user) { User.new(name: "Ava") }
let!(:account) { Account.create!(name: "Main") }

before do
  allow(Time).to receive(:now).and_return(Time.new(2024, 1, 1))
end

Good defaults

• Prefer let over instance variables for simple test data.
• Prefer before for requests, stubs, setup actions, and mutations.
• Keep each helper focused and easy to name.

What is the main difference between RSpec let and before?

let defines a lazily evaluated, memoized helper method. before runs setup code before each example.

Is let better than instance variables in RSpec?

Often yes for simple test data, because it is more explicit, easier to override, and usually easier to read.

When should I use before instead of let?

Use before when you need to perform actions such as making a request, stubbing a method, or changing object state before the example runs.

Why does my let block not run?

Because let is lazy. It only runs when the helper method is called in the example.

What does let! do in RSpec?

let! works like let, but it evaluates before each example, even if you never call it directly.

Can I override let in nested contexts?

Yes. That is one of its biggest benefits in RSpec.

• let! — related because it is the eager version of let.
• before hooks — directly related because they are the main alternative for setup.
• RSpec subject — another helper for defining the main object under test.
• Memoization — explains why let returns the same value within one example.
• Test fixtures and factories — often used together with let in Rails specs.
• RSpec contexts — useful because let can be overridden in nested contexts.
• Instance variables in tests — relevant for understanding the older or simpler setup style.