Convert Figma logo to code with AI

rspec logorspec-core

RSpec runner and formatters

1,233
762
1,233
0

Top Related Projects

Guard::RSpec automatically run your specs (much like autotest)

A library for setting up Ruby objects as test data.

10,029

Acceptance test framework for web applications

Cucumber for Ruby. It's amazing!

5,871

Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.

3,963

Library for stubbing and setting expectations on HTTP requests in Ruby.

Quick Overview

RSpec-core is the heart of RSpec, a popular behavior-driven development (BDD) testing framework for Ruby. It provides a domain-specific language (DSL) for writing human-readable tests and a runner for executing them. RSpec-core is widely used in the Ruby community for writing and running automated tests.

Pros

  • Expressive and readable syntax for writing tests
  • Extensive configuration options and hooks for customization
  • Strong community support and regular updates
  • Integrates well with other Ruby testing tools and frameworks

Cons

  • Learning curve for beginners, especially those new to BDD
  • Can be slower than other testing frameworks for large test suites
  • Some developers find the DSL too "magical" or abstracted
  • Occasional breaking changes between major versions

Code Examples

  1. Basic test structure:
RSpec.describe "Calculator" do
  it "adds two numbers" do
    expect(Calculator.add(2, 3)).to eq(5)
  end
end
  1. Using before hooks:
RSpec.describe User do
  before(:each) do
    @user = User.new("John Doe")
  end

  it "has a name" do
    expect(@user.name).to eq("John Doe")
  end
end
  1. Using context for grouping related tests:
RSpec.describe Order do
  context "when it's empty" do
    it "has 0 total" do
      expect(Order.new.total).to eq(0)
    end
  end

  context "when it has items" do
    it "calculates the total" do
      order = Order.new
      order.add_item(Item.new(price: 10))
      expect(order.total).to eq(10)
    end
  end
end

Getting Started

To start using RSpec-core in your Ruby project:

  1. Add RSpec to your Gemfile:

    gem 'rspec'
    
  2. Install the gem:

    bundle install
    
  3. Initialize RSpec in your project:

    rspec --init
    
  4. Write your tests in the spec directory with filenames ending in _spec.rb.

  5. Run your tests:

    rspec
    

Competitor Comparisons

Guard::RSpec automatically run your specs (much like autotest)

Pros of guard-rspec

  • Automatic test execution on file changes, improving development workflow
  • Integrates with various notification systems for instant feedback
  • Supports running specific tests or groups based on file modifications

Cons of guard-rspec

  • Additional setup and configuration required compared to rspec-core
  • May consume more system resources due to continuous monitoring
  • Potential for false positives or negatives if file watching is unreliable

Code Comparison

rspec-core:

RSpec.describe "Example" do
  it "does something" do
    expect(true).to be true
  end
end

guard-rspec:

guard :rspec, cmd: "bundle exec rspec" do
  watch(%r{^spec/.+_spec\.rb$})
  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }
  watch('spec/spec_helper.rb')  { "spec" }
end

The rspec-core example shows a basic test structure, while the guard-rspec code demonstrates how to set up file watching and test execution rules. guard-rspec builds upon rspec-core, adding automation and continuous testing capabilities to the RSpec testing framework.

A library for setting up Ruby objects as test data.

Pros of Factory Bot

  • Focused on creating test data, making it easier to set up complex object graphs
  • More flexible in creating associations and sequences
  • Lighter weight and faster to execute for data creation tasks

Cons of Factory Bot

  • Limited to object creation, lacking RSpec's full testing framework capabilities
  • Less extensive documentation and community resources
  • Narrower scope of functionality compared to RSpec's comprehensive testing tools

Code Comparison

Factory Bot example:

FactoryBot.define do
  factory :user do
    name { "John Doe" }
    email { "john@example.com" }
  end
end

user = FactoryBot.create(:user)

RSpec example:

RSpec.describe User do
  it "is valid with a name and email" do
    user = User.new(name: "John Doe", email: "john@example.com")
    expect(user).to be_valid
  end
end

Factory Bot excels at creating test data efficiently, while RSpec-Core provides a full-featured testing framework. Factory Bot is ideal for setting up complex object relationships, whereas RSpec-Core offers a more comprehensive suite of testing tools and expectations. The choice between them depends on specific project needs, with many developers using both in conjunction for a robust testing setup.

10,029

Acceptance test framework for web applications

Pros of Capybara

  • Provides a high-level API for web application testing, making it easier to write and maintain integration tests
  • Supports multiple drivers (Selenium, Rack::Test, etc.) allowing for flexible testing across different environments
  • Offers a wide range of powerful matchers and finders for interacting with web elements

Cons of Capybara

  • Limited to web application testing, while RSpec-Core is a general-purpose testing framework
  • Steeper learning curve for beginners due to its domain-specific language and concepts
  • May require additional setup and configuration compared to RSpec-Core's simpler approach

Code Comparison

RSpec-Core:

describe User do
  it "is valid with a name and email" do
    user = User.new(name: "John", email: "john@example.com")
    expect(user).to be_valid
  end
end

Capybara:

feature "User signs in" do
  scenario "with valid credentials" do
    visit "/login"
    fill_in "Email", with: "user@example.com"
    fill_in "Password", with: "password"
    click_button "Sign in"
    expect(page).to have_content "Welcome back!"
  end
end

The code examples demonstrate the different focus areas of each library. RSpec-Core is used for unit testing and behavior specification, while Capybara is designed for integration testing and simulating user interactions with web applications.

Cucumber for Ruby. It's amazing!

Pros of cucumber-ruby

  • More accessible to non-technical stakeholders due to its use of natural language syntax
  • Encourages behavior-driven development (BDD) and collaboration between developers and business analysts
  • Supports a wide range of programming languages beyond Ruby

Cons of cucumber-ruby

  • Can be more verbose and time-consuming to write compared to RSpec
  • May introduce an additional layer of complexity in the testing process
  • Requires more setup and configuration for complex scenarios

Code Comparison

cucumber-ruby:

Feature: User login
  Scenario: Successful login
    Given I am on the login page
    When I enter valid credentials
    Then I should be logged in

rspec-core:

describe "User login" do
  it "allows successful login with valid credentials" do
    visit login_page
    fill_in_credentials
    expect(page).to have_content("Welcome")
  end
end

The cucumber-ruby example uses Gherkin syntax, which is more readable for non-technical team members. The rspec-core example is more concise and closer to Ruby code, making it easier for developers to write and maintain. Both frameworks serve different purposes and can be used together in a project to leverage their respective strengths.

5,871

Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.

Pros of VCR

  • Focuses on recording and replaying HTTP interactions, making it easier to test API integrations
  • Reduces test suite execution time by avoiding real HTTP requests
  • Allows for more stable and predictable tests, especially when dealing with external services

Cons of VCR

  • Limited to HTTP interactions, while RSpec-Core is a general-purpose testing framework
  • Requires additional setup and configuration for each test suite
  • May not capture all edge cases or dynamic responses from real APIs

Code Comparison

VCR example:

VCR.use_cassette("example_cassette") do
  response = Net::HTTP.get_response(URI('http://example.com'))
  expect(response.body).to include("Example Domain")
end

RSpec-Core example:

describe "Example" do
  it "checks the response body" do
    response = Net::HTTP.get_response(URI('http://example.com'))
    expect(response.body).to include("Example Domain")
  end
end

Summary

VCR is specialized for recording and replaying HTTP interactions, making it ideal for testing API integrations and reducing test execution time. RSpec-Core, on the other hand, is a more general-purpose testing framework that provides a wide range of testing capabilities. While VCR excels in its specific use case, it may require additional setup and is limited to HTTP interactions. RSpec-Core offers more flexibility but may not provide the same level of convenience for API testing as VCR does.

3,963

Library for stubbing and setting expectations on HTTP requests in Ruby.

Pros of WebMock

  • Focused specifically on HTTP request stubbing and mocking
  • Supports a wide range of HTTP libraries (Net::HTTP, HTTPClient, Patron, etc.)
  • Provides detailed request matching and response stubbing capabilities

Cons of WebMock

  • Limited to HTTP mocking, while RSpec-Core is a full testing framework
  • May require additional setup and configuration for complex scenarios
  • Less integrated with other testing tools compared to RSpec-Core

Code Comparison

WebMock example:

stub_request(:get, "www.example.com").
  with(headers: {'Accept'=>'*/*', 'User-Agent'=>'Ruby'}).
  to_return(status: 200, body: "stubbed response", headers: {})

RSpec-Core example:

describe "MyClass" do
  it "does something" do
    expect(MyClass.new.some_method).to eq("expected result")
  end
end

Summary

WebMock is a specialized tool for HTTP request mocking, offering detailed control over request stubbing. RSpec-Core, on the other hand, is a comprehensive testing framework for Ruby applications. While WebMock excels in its specific domain, RSpec-Core provides a broader set of testing utilities and is more widely integrated with other Ruby testing tools.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

rspec-core Build Status Code Climate

rspec-core provides the structure for writing executable examples of how your code should behave, and an rspec command with tools to constrain which examples get run and tailor the output.

This is the old rspec core repository, please see the monorepo rspec/rspec for new issues and releases.

Install

gem install rspec      # for rspec-core, rspec-expectations, rspec-mocks
gem install rspec-core # for rspec-core only
rspec --help

Want to run against the main branch? You'll need to include the dependent RSpec repos as well. Add the following to your Gemfile:

%w[rspec rspec-core rspec-expectations rspec-mocks rspec-support].each do |lib|
  gem lib, :git => "https://github.com/rspec/#{lib}.git", :branch => 'main'
end

Basic Structure

RSpec uses the words "describe" and "it" so we can express concepts like a conversation:

"Describe an order."
"It sums the prices of its line items."
RSpec.describe Order do
  it "sums the prices of its line items" do
    order = Order.new

    order.add_entry(LineItem.new(:item => Item.new(
      :price => Money.new(1.11, :USD)
    )))
    order.add_entry(LineItem.new(:item => Item.new(
      :price => Money.new(2.22, :USD),
      :quantity => 2
    )))

    expect(order.total).to eq(Money.new(5.55, :USD))
  end
end

The describe method creates an ExampleGroup. Within the block passed to describe you can declare examples using the it method.

Under the hood, an example group is a class in which the block passed to describe is evaluated. The blocks passed to it are evaluated in the context of an instance of that class.

Nested Groups

You can also declare nested groups using the describe or context methods:

RSpec.describe Order do
  context "with no items" do
    it "behaves one way" do
      # ...
    end
  end

  context "with one item" do
    it "behaves another way" do
      # ...
    end
  end
end

Nested groups are subclasses of the outer example group class, providing the inheritance semantics you'd want for free.

Aliases

You can declare example groups using either describe or context. For a top level example group, describe and context are available off of RSpec. For backwards compatibility, they are also available off of the main object and Module unless you disable monkey patching.

You can declare examples within a group using any of it, specify, or example.

Shared Examples and Contexts

Declare a shared example group using shared_examples, and then include it in any group using include_examples.

RSpec.shared_examples "collections" do |collection_class|
  it "is empty when first created" do
    expect(collection_class.new).to be_empty
  end
end

RSpec.describe Array do
  include_examples "collections", Array
end

RSpec.describe Hash do
  include_examples "collections", Hash
end

Nearly anything that can be declared within an example group can be declared within a shared example group. This includes before, after, and around hooks, let declarations, and nested groups/contexts.

You can also use the names shared_context and include_context. These are pretty much the same as shared_examples and include_examples, providing more accurate naming when you share hooks, let declarations, helper methods, etc, but no examples.

If you want to reuse shared examples or contexts across your RSpec suite you can define them in a stand alone *.rb files (spec/support/shared_examples/definition.rb for example). But you will have to manually require them (there is no autoloading of spec/support/ directory unless you set it up yourself).

Metadata

rspec-core stores a metadata hash with every example and group, which contains their descriptions, the locations at which they were declared, etc, etc. This hash powers many of rspec-core's features, including output formatters (which access descriptions and locations), and filtering before and after hooks.

Although you probably won't ever need this unless you are writing an extension, you can access it from an example like this:

it "does something" do |example|
  expect(example.metadata[:description]).to eq("does something")
end

described_class

When a class is passed to describe, you can access it from an example using the described_class method, which is a wrapper for example.metadata[:described_class].

RSpec.describe Widget do
  example do
    expect(described_class).to equal(Widget)
  end
end

This is useful in extensions or shared example groups in which the specific class is unknown. Taking the collections shared example group from above, we can clean it up a bit using described_class:

RSpec.shared_examples "collections" do
  it "is empty when first created" do
    expect(described_class.new).to be_empty
  end
end

RSpec.describe Array do
  include_examples "collections"
end

RSpec.describe Hash do
  include_examples "collections"
end

A Word on Scope

RSpec has two scopes:

  • Example Group: Example groups are defined by a describe or context block, which is eagerly evaluated when the spec file is loaded. The block is evaluated in the context of a subclass of RSpec::Core::ExampleGroup, or a subclass of the parent example group when you're nesting them.
  • Example: Examples -- typically defined by an it block -- and any other blocks with per-example semantics -- such as a before(:example) hook -- are evaluated in the context of an instance of the example group class to which the example belongs. Examples are not executed when the spec file is loaded; instead, RSpec waits to run any examples until all spec files have been loaded, at which point it can apply filtering, randomization, etc.

To make this more concrete, consider this code snippet:

RSpec.describe "Using an array as a stack" do
  def build_stack
    []
  end

  before(:example) do
    @stack = build_stack
  end

  it 'is initially empty' do
    expect(@stack).to be_empty
  end

  context "after an item has been pushed" do
    before(:example) do
      @stack.push :item
    end

    it 'allows the pushed item to be popped' do
      expect(@stack.pop).to eq(:item)
    end
  end
end

Under the covers, this is (roughly) equivalent to:

class UsingAnArrayAsAStack < RSpec::Core::ExampleGroup
  def build_stack
    []
  end

  def before_example_1
    @stack = build_stack
  end

  def it_is_initially_empty
    expect(@stack).to be_empty
  end

  class AfterAnItemHasBeenPushed < self
    def before_example_2
      @stack.push :item
    end

    def it_allows_the_pushed_item_to_be_popped
      expect(@stack.pop).to eq(:item)
    end
  end
end

To run these examples, RSpec would (roughly) do the following:

example_1 = UsingAnArrayAsAStack.new
example_1.before_example_1
example_1.it_is_initially_empty

example_2 = UsingAnArrayAsAStack::AfterAnItemHasBeenPushed.new
example_2.before_example_1
example_2.before_example_2
example_2.it_allows_the_pushed_item_to_be_popped

The rspec Command

When you install the rspec-core gem, it installs the rspec executable, which you'll use to run rspec. The rspec command comes with many useful options. Run rspec --help to see the complete list.

Store Command Line Options .rspec

You can store command line options in a .rspec file in the project's root directory, and the rspec command will read them as though you typed them on the command line.

Get Started

Start with a simple example of behavior you expect from your system. Do this before you write any implementation code:

# in spec/calculator_spec.rb
RSpec.describe Calculator do
  describe '#add' do
    it 'returns the sum of its arguments' do
      expect(Calculator.new.add(1, 2)).to eq(3)
    end
  end
end

Run this with the rspec command, and watch it fail:

$ rspec spec/calculator_spec.rb
./spec/calculator_spec.rb:1: uninitialized constant Calculator

Address the failure by defining a skeleton of the Calculator class:

# in lib/calculator.rb
class Calculator
  def add(a, b)
  end
end

Be sure to require the implementation file in the spec:

# in spec/calculator_spec.rb
# - RSpec adds ./lib to the $LOAD_PATH
require "calculator"

Now run the spec again, and watch the expectation fail:

$ rspec spec/calculator_spec.rb
F

Failures:

  1) Calculator#add returns the sum of its arguments
     Failure/Error: expect(Calculator.new.add(1, 2)).to eq(3)

       expected: 3
            got: nil

       (compared using ==)
     # ./spec/calculator_spec.rb:6:in `block (3 levels) in <top (required)>'

Finished in 0.00131 seconds (files took 0.10968 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/calculator_spec.rb:5 # Calculator#add returns the sum of its arguments

Implement the simplest solution, by changing the definition of Calculator#add to:

def add(a, b)
  a + b
end

Now run the spec again, and watch it pass:

$ rspec spec/calculator_spec.rb
.

Finished in 0.000315 seconds
1 example, 0 failures

Use the documentation formatter to see the resulting spec:

$ rspec spec/calculator_spec.rb --format doc
Calculator
  #add
    returns the sum of its arguments

Finished in 0.000379 seconds
1 example, 0 failures

Contributing

Once you've set up the environment, you'll need to cd into the working directory of whichever repo you want to work in. From there you can run the specs and cucumber features, and make patches.

NOTE: You do not need to use rspec-dev to work on a specific RSpec repo. You can treat each RSpec repo as an independent project.

Also see