How to Run a Single RSpec Test in Rails

By the end of this page, you will understand how to run a single RSpec test file, how to run one specific example using a line number, and where to execute the command in a Rails project. You will also learn common command variations and mistakes beginners often make.

RSpec is a testing framework for Ruby and Rails. Instead of running the entire test suite every time, you can run only the test file or example you are currently working on.

This matters because:

• it speeds up development
• it makes debugging easier
• it helps you focus on one failing test at a time
• it is the normal workflow in real Rails projects

In a Rails app, RSpec test files are usually stored in the spec/ directory. When you pass a specific file path to RSpec, it runs only that file.

For example:

bundle exec rspec spec/controllers/groups_controller_spec.rb

That tells Bundler to use the gems from your project and tells RSpec exactly which spec file to run.

If you want to run only one example inside that file, you can add a line number:

bundle exec rspec spec/controllers/groups_controller_spec.rb:7

RSpec will run the example closest to that line.

The command should normally be run from the root directory of your Rails project, which is the folder that contains files such as:

• Gemfile
• app/
• config/
• spec/

Running from the project root ensures that relative paths like spec/controllers/groups_controller_spec.rb work correctly.

Think of your test suite like a library.

• Running all specs is like reading every book in the building.
• Running one spec file is like going straight to one shelf.
• Running one example by line number is like opening one exact page.

RSpec lets you point directly to the part you care about right now, instead of searching through everything.

The most common syntax is:

bundle exec rspec path/to/spec_file.rb

For your file:

bundle exec rspec spec/controllers/groups_controller_spec.rb

Run this from the Rails project root.

Run a single example by line number

bundle exec rspec spec/controllers/groups_controller_spec.rb:7

This runs the example nearest line 7.

Older command style

In older RSpec/Rails setups, you may also see:

bundle exec spec spec/controllers/groups_controller_spec.rb

Because your project uses rspec-rails ~> 2.4, this older style may exist in some tutorials or codebases. However, bundle exec rspec ... is the clearer and more commonly recognized form.

Example workflow

cd my_rails_app
bundle exec rspec spec/controllers/groups_controller_spec.rb

Explanation:

• cd my_rails_app moves into the Rails app root

Consider this command:

bundle exec rspec spec/controllers/groups_controller_spec.rb

Here is what happens step by step:

1. bundle exec loads the gem versions from your project's Gemfile.lock.
2. rspec starts the RSpec test runner.
3. spec/controllers/groups_controller_spec.rb tells RSpec to load only that file.
4. RSpec reads the file:

require 'spec_helper'

describe GroupsController do
  describe "GET yourgroups" do
    it "should be successful and return 3 items" do
      get :yourgroups, :format => :json
      response.should be_success
    end
  end
end

1. RSpec finds one example:

it "should be successful and return 3 items" do

1. It runs that example.
2. If it passes, you see output showing 1 example, 0 failures.

Developers run single RSpec tests all the time in situations like these:

• Debugging one failing controller spec

  • You change one action and want to retest only its spec file.

• Working on a new feature

  • You write one spec first, then run just that spec repeatedly while implementing the code.

• Fixing flaky tests

  • You isolate one spec and run it several times.

• Improving slow feedback loops

  • Instead of waiting for hundreds of tests, you run the relevant file only.

• CI failure reproduction

  • A CI job reports one failing spec file, and you run that file locally to investigate.

• Refactoring legacy code

  • You focus on one spec area, such as controllers, models, or services, before running the whole suite later.

In real projects, developers commonly combine single-spec execution with a few practical patterns.

Focused debugging

Run one file while changing code:

bundle exec rspec spec/controllers/groups_controller_spec.rb

Run one exact example

When a file contains many examples, use a line number:

bundle exec rspec spec/controllers/groups_controller_spec.rb:8

Guard clauses in test workflow

Developers often start small:

1. run one example
2. run one file
3. run a related folder
4. run the full suite

Validation after local changes

If you edit a controller action, you might run:

• the related controller spec file first
• then related request or model specs
• finally the whole suite before committing

Common team habits

In mature Rails codebases, you will often see scripts or aliases such as:

bin/rspec spec/controllers/groups_controller_spec.rb

This is common in newer apps. In older apps, bundle exec rspec is more typical.

Error-focused iteration

When a test fails, developers use the file path from the error output and rerun only that file or line. This shortens the fix-and-verify cycle significantly.

1. Running the command from the wrong directory

If you are not in the Rails project root, the relative path may not work.

Broken example:

cd spec/controllers
bundle exec rspec spec/controllers/groups_controller_spec.rb

Why it fails:

• the path is now wrong relative to your current directory

Better:

cd /path/to/your/app
bundle exec rspec spec/controllers/groups_controller_spec.rb

2. Forgetting bundle exec

Broken example:

rspec spec/controllers/groups_controller_spec.rb

This may use a global RSpec version instead of your app's version.

Better:

bundle exec rspec spec/controllers/groups_controller_spec.rb

3. Using the wrong file path

Broken example:

bundle exec rspec controllers/groups_controller_spec.rb

Better:

rspec vs spec

# Run all specs
bundle exec rspec

# Run one spec file
bundle exec rspec spec/controllers/groups_controller_spec.rb

# Run one example by line number
bundle exec rspec spec/controllers/groups_controller_spec.rb:7

# Run all controller specs
bundle exec rspec spec/controllers

Where to run the command

Run it from the Rails project root, the directory containing:

• Gemfile
• app/
• config/
• spec/

For your question

Use:

bundle exec rspec spec/controllers/groups_controller_spec.rb

Key rules

• Use bundle exec to ensure the correct gem versions
• Use the path relative to the project root
• Add :line_number to run one example
• In older setups, bundle exec spec ... may also appear

What command runs only one RSpec file?

Use:

bundle exec rspec spec/controllers/groups_controller_spec.rb

Where should I run the RSpec command?

Run it from the root of the Rails project, where the Gemfile and spec directory are located.

How do I run only one test inside a spec file?

Add the line number of the example:

bundle exec rspec spec/controllers/groups_controller_spec.rb:7

Why should I use bundle exec?

It ensures Ruby uses the gem versions installed for your project instead of globally installed gems.

Can I run a whole folder of specs?

Yes.

bundle exec rspec spec/controllers

My project is old. Should I use spec or rspec?

Older projects sometimes use bundle exec spec ..., but bundle exec rspec ... is the standard command to try first.

Does running one spec file skip Rails setup?

• RSpec basics - Helps you understand examples, groups, and expectations.
• Rails testing - Provides context for controller, model, and request specs.
• Bundler - Explains why bundle exec matters.
• Command line basics - Useful for navigating to the correct project directory.
• Test-driven development - Single-test execution is a common TDD workflow.
• RSpec line numbers - Useful for running one specific example.
• Spec file structure - Helps you understand how RSpec organizes tests.