User:Jigesh.1992/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, got interested by the idea of developing a testing framework based on the behavior, given by Dave Astels and Aslak Hellesøy. 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 RSpec-2, was released in October 2010, after bringing together the efforts of David and Chad. Later in November 2012, Myron Marston was appointed as the lead RSpec maintainer and Andy Lindeman as the lead RSpec-Rails maintainer. RSpec 3 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:

Running Examples
The RSpec code is written inside your_file_spec.rb which resides in the spec folder. In order to execute this code use the following command: or we could run: or 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  class representing a group of examples that could be executed is declared with   method.
 * The  method declares an example and inside the   method any number of   methods could be used to specify that number of examples.
 * The  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.
 * A  block could be specified in order to give some context to the examples mentioned inside this block.
 * and  method comes from Rpsec-core and   method is from RSpec-expectations.
 * A  block could be specified inside the   block such that an initialization of object or a valid state of object going to be used by all examples could be set before each example runs. A   block could be specified that runs only once before all the examples in an example group run.
 * Similarly code to be ran after an example completes could be specified in  block.

Consider the following example from a conversation : Corresponding RSpec code: The string passed to the  method specifies that the given example is for summing the prices of its items. The  method line suggests that if   is equal to the value returned by , then the example passes otherwise it fails with a message like:

Consider another example: In the above RSpec code,  specifies a   for the examples (i.e.   and  ) of the   class. The  block is executed before each example such that an instance variable   is initialized for the examples. The  method in the examples checks that the   is not null and also   is not false.

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 the customer name using  method and then   method calls for the customer name & customer double returns the name using   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  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. The  is specified for model spec.

Usage Example: The above example is used to test whether the two newly created users are ordered by their last names using  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  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  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. 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. A tag  indicates that it is a routing spec.

In the above example, the routing spec expects the  request to be routed to the controller action. The test passes only if that is true.

Upgrade note : syntax is replaced with  and   in the versions after rails 1-x.

View Specs
View specs are used to provide data to a particular view template and expect certain state regarding the content rendered.

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. The test is passed when text matches with the argument of  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  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 delegates to the command assert_template in Rails.
 * It is present in request specs, controller specs and view specs.

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

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.