RSpec - Misplaced Pages

This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (February 2017) (Learn how and when to remove this message)

RSpec
Developer(s)	Steven Baker, David Chelimsky, Myron Marston, Andy Lindeman, Jon Rowe, Paul Casaretto, Sam Phippen, Bradley Schaefer
Initial release	May 18, 2007; 17 years ago (2007-05-18)

Stable release	3.13.0 / 4 February 2024; 9 months ago (4 February 2024)

Repository	github.com/rspec/rspec-rails
Operating system	Cross-platform
Type	Behavior driven development framework / Test tool
License	MIT License
Website	rspec.info

RSpec is a computer domain-specific language (DSL) (particular application domain) testing tool written in the programming language Ruby to test Ruby code. It is a behavior-driven development (BDD) framework which is extensively used in production applications. The basic idea behind this concept is that of test-driven development (TDD) where the tests are written first and the development is based on writing just enough code that will fulfill those tests followed by refactoring. It contains its own mocking framework that is fully integrated into the framework based upon JMock. The simplicity in the RSpec syntax makes it one of the popular testing tools for Ruby applications. The RSpec tool can be used by installing the rspec gem which consists of three other gems, namely rspec-core, rspec-expectation and rspec-mock.

History

RSpec was started as an experiment by Steven Baker in 2005 along with his team members Dave Astels, Aslak Hellesøy and David Chelimsky. Chelimsky was responsible for developing the RSpec-Rails which facilitated the integration with Ruby on Rails. The initial release i.e. RSpec 1.0 came out in May 2007 which contained many prime features of RSpec which are being included in the latest releases too. However, due to some technical issues such as testing speed, it was discontinued later. The third version of RSpec i.e. the RSpec 3 was released in July 2014 which had many new features like verify doubles, composable matchers and many more.

Usage

Describing the behavior of objects

As mentioned above, RSpec provides a domain-specific language to describe the behavior of objects. The keywords used in RSpec are similar to the ones used in other languages and/or TDD frameworks. For example, if the keywords used in Test::Unit are considered, they can be mapped to the RSpec keywords as follows:

Assertion becomes expectation
Test method becomes Example code
Test case becomes Example group

There are many such keywords which are used in the same context but with the similar names. The syntax of RSpec provides the ease of readability and describes the behavior of the code thereby providing freedom to the programmer. Every testing framework works in the following flow - given some context, when some event occurs, what outcome is expected. The methods like describe(), context() and it() form the analogy and the skeleton respectively of the test code.

describe()

The describe() method is used to describe a class, method or an example group. This is the outer block which actually contains the test code and it depicts the characteristics of the code enclosed in it. This method takes a number of arguments and an optional block. However, normally one or two arguments are used to describe the behavior of the example group. The first argument represents the reference to the class or module whereas the second argument is optional whose datatype would be String. The example groups can be nested as well. An example of using the describe method is as follows:

describe User, "with no account balance" {....}
=> User with no account balance

context()

The context() block is used to describe the context in which the class or method mentioned in the describe block is being used. This can be considered as an alias to the word describe() in this scenario and they both can be used interchangeably. Generally, describe() is used for things and context() is used for contexts. It helps to venture out different outcomes in different scenarios. The example mentioned above can be described using the context() method as follows:

describe User do
  context "has no account balance" do
    ....
  end
end

Using context() makes it easier to scan a spec file and makes it clear what it relates to.

it()

It is a RSpec method which describes the specifications of the sample in the context. The it() block takes a string as an argument and the string after the 'it' keyword can be considered as the function that the block is expected to perform or in other words it can be considered as a test case. Consider the following example:

describe User do
  context "has no account balance" do
    it "is not allowed to sanction a housing loan" do
      puts "The loan cannot be sanctioned due to no balance in the account."
    end
  end
end

RSpec::Expectations

In RSpec, an expectation is a statement expressing the state that something is expected to be in, at a particular point in the execution of a code example. RSpec uses a simple framework and keywords like should() and should_not() to express expectations. It supports matchers, that is objects that try to match an expected outcome, for common operations as well as uncommon expressions. For example, if the expected outcome of a result is say numeric value 5, a RSpec expectation that uses the matcher equal for the same would be written as follows:

result.should equal(5)

RSpec::Mocks

RSpec provides a library called RSpec::Mocks in order to create test doubles that facilitate focusing on roles, interface discovery, but most of all making progress without implemented dependencies thereby providing isolation from coupling and non determinism.

Tools and integration

RSpec has support from numerous text editors and coverage suites. RSpec also provides a number of utilities and extension points to support extending RSpec to meet domain-specific needs. For instance, using Metadata associated with groups and examples for the purpose of reporting, using global configuration to assign before and after blocks to every example group, using macros etc.