RSpec

Last updated
RSpec
Developer(s) Steven Baker, David Chelimsky, Myron Marston, Andy Lindeman, Jon Rowe, Paul Casaretto, Sam Phippen, Bradley Schaefer [1]
Initial releaseMay 18, 2007;16 years ago (2007-05-18) [2]
Stable release
3.13.0 [3]   OOjs UI icon edit-ltr-progressive.svg / 4 February 2024;48 days ago (4 February 2024)
Repository
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. [4] 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. [5] 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. [4]

Contents

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. [6] For example, if the keywords used in Test::Unit are considered, they can be mapped to the RSpec keywords as follows:

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. [6] 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. [6] The example groups can be nested as well. An example of using the describe method is as follows: [6] 

describeUser,"with no account balance"{....}=>Userwithnoaccountbalance

[6]

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: [6] 

describeUserdocontext"has no account balance"do....endend

[6] 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: [6] 

describeUserdocontext"has no account balance"doit"is not allowed to sanction a housing loan"doputs"The loan cannot be sanctioned due to no balance in the account."endendend

[6]

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: [6]

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. [6]

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.

Other Ruby testing tools

Related Research Articles

<span class="mw-page-title-main">Smalltalk</span> Object-oriented programming language released first in 1972

Smalltalk is a purely object oriented programming language (OOP) that was originally created in the 1970s for educational use, specifically for constructionist learning, but later found use in business. It was created at Xerox PARC by Learning Research Group (LRG) scientists, including Alan Kay, Dan Ingalls, Adele Goldberg, Ted Kaehler, Diana Merry, and Scott Wallace.

In computer programming, unit testing is a software testing method by which individual units of source code—sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures—are tested to determine whether they are fit for use. It is a standard step in development and implementation approaches such as Agile.

Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.

<span class="mw-page-title-main">Apache Groovy</span> Programming language

Apache Groovy is a Java-syntax-compatible object-oriented programming language for the Java platform. It is both a static and dynamic language with features similar to those of Python, Ruby, and Smalltalk. It can be used as both a programming language and a scripting language for the Java Platform, is compiled to Java virtual machine (JVM) bytecode, and interoperates seamlessly with other Java code and libraries. Groovy uses a curly-bracket syntax similar to Java's. Groovy supports closures, multiline strings, and expressions embedded in strings. Much of Groovy's power lies in its AST transformations, triggered through annotations.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

A method stub or simply stub in software development is a piece of code used to stand in for some other programming functionality. A stub may simulate the behavior of existing code or be a temporary substitute for yet-to-be-developed code. Stubs are therefore most useful in porting, distributed computing as well as general software development and testing.

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing.

<span class="mw-page-title-main">Factory (object-oriented programming)</span> Object that creates other objects

In object-oriented programming, a factory is an object for creating other objects; formally, it is a function or method that returns objects of a varying prototype or class from some method call, which is assumed to be "new". More broadly, a subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function. The factory pattern is the basis for a number of related software design patterns.

In object-oriented programming, mock objects are simulated objects that mimic the behaviour of real objects in controlled ways, most often as part of a software testing initiative. A programmer typically creates a mock object to test the behaviour of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behaviour of a human in vehicle impacts. The technique is also applicable in generic programming.

In software engineering, behavior-driven development (BDD) is a software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD) and can work alongside an agile software development process. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Keyword-driven testing, also known as action word based testing, is a software testing methodology suitable for both manual and automated testing. This method separates the documentation of test cases – including both the data and functionality to use – from the prescription of the way the test cases are executed. As a result, it separates the test creation process into two distinct stages: a design and development stage, and an execution stage. The design substage covers the requirement analysis and assessment and the data analysis, definition, and population.

Mockito is an open source testing framework for Java released under the MIT License. The framework allows the creation of test double objects in automated unit tests for the purpose of test-driven development (TDD) or behavior-driven development (BDD).

<span class="mw-page-title-main">Jasmine (software)</span> Open-source testing framework for JavaScript

Jasmine is an open-source testing framework for JavaScript. It aims to run on any JavaScript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax. It is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec.

Cucumber is a software tool that supports behavior-driven development (BDD). Central to the Cucumber BDD approach is its ordinary language parser called Gherkin. It allows expected software behaviors to be specified in a logical language that customers can understand. As such, Cucumber allows the execution of feature documentation written in business-facing text. It is often used for testing other software. It runs automated acceptance tests written in a behavior-driven development (BDD) style.

Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE), behavior-driven development (BDD), example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer's needs prior to implementation and allow customers to be able to converse in their own domain language.

<span class="mw-page-title-main">Behat (software)</span>

Behat is a test framework for behavior-driven development written in the PHP programming language. Behat was created by Konstantin Kudryashov and its development is hosted on GitHub.

EasyMock is an open-source testing framework for Java released under the Apache License. The framework allows the creation of test double objects for the purpose of Test-driven Development (TDD) or Behavior Driven Development (BDD).

Capybara is a web-based test automation software that simulates scenarios for user stories and automates web application testing for behavior-driven software development. It is written in the Ruby programming language.

Factory Bot, originally known as Factory Girl, is a software library for the Ruby programming language that provides factory methods to create test fixtures for automated software testing. The fixture objects can be created on the fly; they may be plain Ruby objects with a predefined state, ORM objects with existing database records or mock objects.

Bogus is a Ruby API library used for minimizing risks involved in isolated unit testing. It was initially released in July 2012 by rubygems.org. Through Bogus, a piece of code can be tested in a fast and safe manner, without any actual integration with external programs. Bogus cannot mock or stub methods not present in the required external environment.

References

  1. ↑ RSpec core team. Retrieved 8 April 2013.
  2. ↑ "all versions of rspec". rubygems.org. Retrieved 11 February 2014.
  3. ↑ "Release 3.13.0". 4 February 2024. Retrieved 20 February 2024.
  4. 1 2 "Introduction to RSpec | The Odin Project". www.theodinproject.com. Retrieved 2017-02-18.
  5. ↑ "jMock - An Expressive Mock Object Library for Java". www.jmock.org. Retrieved 2017-02-18.
  6. 1 2 3 4 5 6 7 8 9 10 11 "The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North | The Pragmatic Bookshelf". pragprog.com. Retrieved 2017-02-11.


Further reading

1. Getting started with RSpec: (installation steps) http://rspec.info/

2. Beck, K. (2014). Test-driven development by example. Boston: Addison-Wesley.

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.