User:Anushbonam/Rspec

RSpec is a behavior-driven development (BDD) framework for the Ruby programming language, inspired by JBehave. 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
It started back in 2005, when Steve was interested in the idea, given by Dave Astels and Aslak Hellesøy, 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 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.

Installation
A gem must be added inside the GEMFILE in order to install rspec:

Then run the following command:

To install rspec-rails for versions later to 3.x add to GEMFILE:

Then run:

Rspec-core & Rspec-expectations
The 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: Corresponding Rspec code: 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:

Rspec-mocks
Rspec-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: 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.

Rspec-rails
A testing framework for rails 3.x and 4.x. The rails specs reside in the spec/ 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
Model specs are used to specify the behavior of a model.

Usage Example: 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
Controller 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.

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
Request specs are used to define single/multiple request and response cycles. The :type=> :request is specified for request spec.

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
Routing 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.

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  and   in the versions after rails 1-x.

View Specs
View specs are used to render the view templates and reside in the specs/views folder by default.

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

Used in versions later to rspec-rails-2.x

Matchers
Matchers 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.

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”. In view specs, the view object is rendered.

redirect_to For example,the redirect_to matcher is used to test whether the response object is redirected to the correct path.
 * It is present in request specs and controller specs.
 * It delegates to the command assert_redirect in Rails.

Routing matchers like route_to and be_routable are used to test whether the object is routed to the correct Rails routing.

route_to be_routable
 * It is present in routing specs and controller specs.
 * It delegates to the command assert_routing in Rails.
 * 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.