Developer(s) | David Chelimsky, Myron Marston, Andy Lindeman, Jon Rowe, Paul Casaretto, Sam Phippen, Bradley Schaefer[1] |
---|---|
Initial release | May 18, 2007[2] |
Stable release | 3.3.0 [3]
/ June 12, 2015 |
Operating system | Cross-platform |
Type | Behavior driven development framework / Test tool |
License | MIT License |
Website | rspec |
RSpec is a behavior-driven development (BDD) framework for the Ruby programming language, inspired by JBehave.[4] It contains its own mocking framework that is fully integrated into the framework based upon JMock. The framework can be considered a domain-specific language (DSL) and resembles a natural language specification.
History
editIt started back in 2005, when Steve was interested in the idea, given by Dave Astels[5] and Aslak Hellesøy[6] , for developing testing framework based on the behavior. This marked the beginning of RSpec. Later in 2006, David Chelimsky lead the team and released a rspec-rails framework for Ruby on Rails.
In the May of 2007, the team was able to release RSpec 1.0 which included many vital features that are still in use today. The next stable version, RSpec2 was released in October 2010, after bringing together the efforts of David and Chad. Later in November 2012, Myron Marston was made the lead RSpec maintainer and Andy Lindeman was made the lead rspec-rails maintainer. RSpec3[7] was released in June 2014 with many new features such as verifying doubles, composable matchers, a syntax which doesn’t require monkey patching and many other new features[8].
Installation
editA gem must be added inside the GEMFILE in order to install rspec:
source 'https://rubygems.org'
gem 'rspec', '~> 3.3.0'
Then run the following command:
gem install rspec # installs rspec-core, rspec-expectations and rspec-mocks
gem install rspec-core # installs rspec-core only
To install rspec-rails for versions later to 3.x add to GEMFILE:
# The gem needs to be added to both development and test groups.
group :development, :test do
gem 'rspec-rails', '~> 3.0'
end
Then run:
bundle install
Components
editRspec-core & Rspec-expectations
editThe structure for a particular behavior of the instance of a class is specified by rspec-core and the expected output is specified by rspec-expectation. The following basic structure is followed by an rspec code:
- The ExampleGroup class representing a group of examples that could be executed is declared with describe() method.
- The it() method declares an example and inside the describe method any number of it() methods could be used to specify that number of examples.
- The expect() method is used to compare the desired and obtained output of executing the example and hence it determines the pass/fail result of that example.
- describe() and it() method comes from rpsec-core and expect() method is from rspec-expectations.
- A before(:each) block could be specified inside the describe block such that an initialization of object or a valid state of object going to be used by all tests could be set before each test runs. SImilarly code to be executed after an example completes could be specified in after() block.
Consider the following example from a conversation:
"Describe an order."
"It sums the prices of its line items."
Corresponding Rspec code:
#Testing for Order class
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 behavior of Order class instance, in the above example, would be summing the prices of its items. The expect() method line suggests that if order.total is equal to the value returned by Money.new(5.55, :USD), then the example passes otherwise it fails with a message like:
expected: #<Money @value=5.55 @currency=:USD>
got: #<Money @value=1.11 @currency=:USD>
Rspec-mocks
editRspec-mocks provides features like Test double which represent real objects during the test. It also provides fake method implementations and set expectations on messages received by objects.
Consider an example:
# Testing for Statement class
describe Statement do
it "uses the customer's name in the header" do
customer = double('customer')
customer.should_receive(:name).and_return('Aslak')
statement = Statement.new(customer)
statement.generate.should =~ /^Statement for Aslak/
end
end
Here, in the above example, a test-double for customer object is created which represents the object in the test. The test is passed if it verifies for the customer name using should_receive() method and then generate() method calls for the customer name & customer double returns the name using return() method.
Test-doubles are used to represent objects that are not been created at that point. But verifying-doubles represent an existing object in the system.
book = instance_double("Book", :pages => 250)
Rspec-rails
editA testing framework for rails 3.x and 4.x. The rails specs reside in the spec/<spec-name> directory by default. The documentation specifies various rails specs namely: model specs, controller specs, request specs, feature specs, view specs, routing specs and helper specs.
Model Specs
editModel specs are used to specify the behavior of a model.
Usage Example:
require "rails_helper"
RSpec.describe User, :type => :model do
it "orders by last name" do
lindeman = User.create!(first_name: "Andy", last_name: "Lindeman")
chelimsky = User.create!(first_name: "David", last_name: "Chelimsky")
expect(User.ordered_by_last_name).to eq([chelimsky, lindeman])
end
end
The above example is used to test whether the two newly created users are ordered by their last names using ordered_by_last_name method.
Controller Specs
editController specs are group of specs that determine the behavior of the actions of a particular controller. It does not render the view template by default and can run in complete isolation from model and views but it is necessary that the view template must be present.
require "rails_helper"
RSpec.describe PostsController, :type => :controller do
describe "GET #index" do
it "responds successfully with an HTTP 200 status code" do
get :index
expect(response).to be_success
expect(response).to have_http_status(200)
end
it "renders the index template" do
get :index
expect(response).to render_template("index")
end
expect(assigns(:posts)).to match_array([post1, post2])
end
end
end
In the above example, the PostsController index action is checked to see whether the correct HTTP code is received and in another example whether the correct index template is received as response.
Request Specs
editRequest specs are used to define single/multiple request and response cycles. The :type=> :request is specified for request spec.
require 'rails_helper'
RSpec.describe "home page", :type => :request do
it "displays the user's username after successful login" do
user = User.create!(:username => "jdoe", :password => "secret")
get "/login"
assert_select "form.login" do
assert_select "input[name=?]", "username"
assert_select "input[name=?]", "password"
assert_select "input[type=?]", "submit"
end
post "/login", :username => "jdoe", :password => "secret"
assert_select ".header .username", :text => "jdoe"
end
end
The above example tests the entire login process by first creating a user with username and password, then rendering the login page and entering details inside the login form, submitting the form and then checking that the page after logging in contains the user name. assert_select() method is an assertion that selects elements and performs one or more equality tests.
Routing Specs
editRouting specs are used to test whether a specific route maps to a specific controller and its respective action. Routing specs are by default in the “spec/routing” folder. A tag :type => :routing indicates that it is a routing spec.
require 'rails_helper'
RSpec.describe "routing to profiles", :type => :routing do
it "routes /profile/:username to profile#show for username" do
expect(:get => "/profiles/jsmith").to route_to(
:controller => "profiles",
:action => "show",
:username => "jsmith")
end
it "does not expose a list of profiles" do
expect(:get => "/profiles").not_to be_routable
end
end
In the above example, the routing spec expects the /profile/jsmith request to be routed to the controller action “profiles#show#jsmith”. The test passes only if that is true.
Upgrade note:
route_for syntax is replaced with
route_to
and
be_routable
in the versions after rails 1-x.
View Specs
editView specs are used to render the view templates and reside in the specs/views folder by default.
require 'spec_helper'
describe "messages/show.html.erb" do
it "displays the text attribute of the message" do
assign(:message, double("Message", :text => "Hello world!"))
render
rendered.should contain("Hello world!")
end
end
In the above example, text in a message is displayed. This method is tested by creating test double and returning “Hello world!” text to the instance variable @message. The test is passed when text matches with the argument of contain() matcher.
Upgrade note: Used till rspec-rails - 1.x
assigns[key] = value
render
response.should xxx
Used in versions later to rspec-rails-2.x
assign(key, value)
render
expect(rendered).to xxx
Matchers
editMatchers like be_a_new, render_template, redirect_to, route_to and be_routable are used to match the object with expected outcome along with the expect() method. be_a_new
- It checks if the object is new record.
- This matcher is used mainly in controller specs, though available in all specs.
expect(object).to be_a_new(Widget)
render_template
- It is present in request specs, controller specs and view specs.
- It delegates to the command assert_template in Rails.
In request and controller specs, it is used to render the response object to “new”.
expect(response).to render_template("new")
In view specs, the view object is rendered.
expect(view).to render_template(:partial => "_form", :locals => { :widget => widget } )
redirect_to
- It is present in request specs and controller specs.
- It delegates to the command assert_redirect in Rails.
For example,the redirect_to() matcher is used to test whether the response object is redirected to the correct path.
expect(response).to redirect_to(widgets_path)
Routing matchers like route_to() and be_routable() are used to test whether the object is routed to the correct Rails routing.
route_to
- It is present in routing specs and controller specs.
- It delegates to the command assert_routing in Rails.
expect(:get => "/widgets").to route_to(:controller => "widgets", :action => "index")
be_routable
- This matcher is used to test if a path is recognized by Rails routing.
- This can also be used along with not_to to test routes which should not be routable.
expect(:get => "/widgets/1/edit").not_to be_routable
Usage Examples
editdescribe User do
context 'with admin privileges' do
before :each do
@admin = Admin.get(1)
end
it 'should exist' do
expect(@admin).not_to be_nil
end
it 'should have a name' do
expect(@admin.name).not_to be_false
end
end
end
See also
editReferences
edit- ^ RSpec core team. Retrieved 8 April 2013.
- ^ "all versions of rspec". rubygems.org. Retrieved 11 February 2014.
- ^ http://rubygems.org/gems/rspec/versions/3.3.0
- ^ Ed Gibbs, JBehave and RSpec History (Blog entry)
- ^ "Dave Astels". GitHub.
- ^ "Aslak Hellesøy".
- ^ "Rspec3".
- ^ "New features of Spec-3.0.0".
Further reading
edit- Chelimsky, David; Astels, Dave; Helmkamp, Bryan; North, Dan; Dennis, Zach; Hellesoy, Aslak (December 22, 2010). The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends (First ed.). Pragmatic Bookshelf. p. 448. ISBN 978-1934356371.
External links
edit- Official website
- RSpec-2
- Beyond Test Driven Development - Behaviour Driven Development. A Google TechTalk by Dave Astels on BDD using RSpec.
- RSpec Best Practices Article by Jared Carroll, retrieved April 24 2011.
- Behavior-driven testing with RSpec Article by Bruce Tate, retrieved July 21 2011.
Category:Software testing tools Category:Software using the MIT license