CSC/ECE 517 Fall 2012/ch1 1w3 pl: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(60 intermediate revisions by 2 users not shown)
Line 7: Line 7:
=Introduction=
=Introduction=


Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases which are written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.
Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for Ruby are Shoulda, RSpec and Cucumber.


=Cucumber=
=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to behaviour driven development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD).  Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD).  Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.


==Behaviour Driven Development(BDD)==
==Behaviour Driven Development(BDD)==


Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.
Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non-programming background). In this approach we write tests in a natural language that even a non-programmer can understand.


==Acceptance Test==
==Acceptance Test==


Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly get to know when our development phase is over. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.
Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.


===Cucumber Acceptance Test===
===Cucumber Acceptance Test===
Line 42: Line 42:
==How Cucumber works==  
==How Cucumber works==  


Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against your system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step.
Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.  
 
Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input. Cucumber acts as the bridge between the customer and the developer. User stories are customer understandable but at the same time can be used to create test cases from it. This does pose some restrictions on the user stories that are written.


===Feature===
===Feature===
A Feature is a high level statement of the what the test case actually does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory.The feature files usually end with .feature extension.
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.


===Scenario===
===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature.  There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it.  The Steps of the scenario always begin with one of the below mentioned key words :  
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature.  There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it.  The steps of the scenario always begin with one of the below mentioned key words :  


1. <b>Given</b> : Steps that begin with given represent the state of the world before an event.(preconditions)<br>
1. <b>Given</b> : Steps that begin with given represent the state of the world before an event.(preconditions)<br>
Line 58: Line 56:


===Step and Step Definitions===
===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to  method definitions and steps of scenarios are analogous to method calls.Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to  method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.


When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.
When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>


====Successful steps====
====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green).


====Undefined steps====
====Undefined steps====
Line 72: Line 70:


====Failed steps====
====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. What you return from a Step Definition has no significance what so ever. Returning nil or false will not cause a step definition to fail.
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.


Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : <br>
Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : <br>
Line 81: Line 79:
4. Blue : Once a step fails all the successive steps are marked in blue.<br>
4. Blue : Once a step fails all the successive steps are marked in blue.<br>


==Cucumber Testing Stack==
[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]
/* Some Content */
 
[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]


==Advantages of Cucumber==
==Advantages of Cucumber==
*Specifications can be written in  more than forty different spoken languages.
*Specifications can be written in  more than forty different spoken languages.
*Cucumber helps build bridges between the technical and non-technical members of a software team.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick , easy , efficient and understandable.
*Writing Cucumber tests are quick, easy, efficient and understandable.


=Cucumber Installation=
=Cucumber Installation=


To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run   
 
To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run   
      
      
     gem install cucumber  
     gem install cucumber  
Line 107: Line 103:


     gem install rspec
     gem install rspec
Cucumber depends on a particular gherkin version which will be downloaded automatically when we install Cucumber. Suppose we have a later version of gherkin installed in our system then RubyGems get confused and hence the required version of gherkin will not be downloaded and used. In order to resolve this issue we might have to give this command :
    gem install gherkin --version 2.2.9


=Testing a Sample Ruby Application using Cucumber=
=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.


Step 1 : Create a new directory  
Step 1 : Create a new directory  
Line 124: Line 116:
     gem instal rspec
     gem instal rspec


Step 3 : Create a directory features and create a file basic.feature in the features directory mkdir features
Step 3 : Create a directory features and create a file basic.feature in the features directory


       mkdir features
       mkdir features
Line 131: Line 123:


     <b>Feature</b>: Hello World Feature<br>
     <b>Feature</b>: Hello World Feature<br>
     <b>Scenario</b>: Hello World Scenario
     <b>Scenario</b>: Hello World Scenario
     Given The Action is Hello
     Given The Action is Hello
Line 137: Line 128:
     Then The Greeting is Hello, World
     Then The Greeting is Hello, World


Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_difinitions.
Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.


       mkdir features/step_definitions
       mkdir features/step_definitions


The directory structure looks like this
[[File:Dirstructure.JPG|400px|thumb|center|Directory structure]]
<br>
Content of <b>features/step_definitions/basic_step.rb</b>
Content of <b>features/step_definitions/basic_step.rb</b>
        
        
Line 154: Line 149:
       end
       end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.


Step 5: Running cucumber command you will see the following output  
Step 5: Running cucumber command you will see the following output  
Line 200: Line 196:
     0m0.033s
     0m0.033s


The Bye Scenario fails since the expected output is “Hello, World” but the resulting output is “Bye,World”.
The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.


=Testing a Sample Rails Application using Cucumber=
=Testing a Sample Rails Application using Cucumber=


Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Let us consider we create a new applications using the following command :
 
Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.


     rails new cucumber_app
     rails new cucumber_app
<br>
and the new applications with its folders get created.


we would have to install the gems required for running Cucumber with Rails and there are couple of gems that are required and they can be installed with the following command :
Install the required cucumber gems
<br>
<br>
     gem install cucumber
     gem install cucumber
     gem install cucumber cucumber-rails  
     gem install cucumber cucumber-rails  
<br>
 
We would have to then give “bundle install” command to install these new gems. We would then have to update the Gemfile to include these gems in the test group since they will be needed only in the test environment. There are a few other gems which are required for cucumber namely database_cleaner , rspec-rails and webrat.
Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
<br>
<br>
     group :test do
     group :test do
       gem 'database_cleaner'
       gem 'database_cleaner'
       gem 'cucumber'
       gem 'cucumber'
Line 224: Line 218:
       gem "cucumber-rails", "1.0.6"
       gem "cucumber-rails", "1.0.6"
       gem 'webrat'
       gem 'webrat'
      end
    end
 
After modifying the gem file, run bundle update
 
      bundle update
 
The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.
 
    rails generate cucumber:install
<br>
    identical  script/cucumber
          chmod  script/cucumber
          exist  features/step_definitions
    identical  features/step_definitions/web_steps.rb
          exist  features/support
    identical  features/support/paths.rb
    identical  features/support/selectors.rb
    identical  features/support/env.rb
          exist  lib/tasks
    identical  lib/tasks/cucumber.rake
<br>
The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
<br>
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
<br>
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
<br>
    rails generate model article title:string content:text
    rake db:migrate
    rake db:test:clone
    rails generate controller articles index
<br>
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
<br>
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed. 
 
    => cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>
 
We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.


=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=
=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=
<ref>[http://pragprog.com/book/achbd/the-rspec-book Book on Cucumber and RSpec]</ref>


{|border="2" cellpadding="5" cellspacing="0" align="center"
{|border="2" cellpadding="5" cellspacing="0" align="center"
Line 241: Line 277:
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.  
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.  
|Shoulda provides macros, helpers and matchers.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|Cucumber allows the test cases to be written in native languages.
|-
|-
|RSpec too allows nested describe structure.
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures  
|Cucumber is similar to RSpec and provides nested structures.
|-
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.  
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.  
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.  
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.  
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.
|Cucumber is  more descriptive and allows business stakeholder to read and write test specification.


|}
|}
=Summary=
Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project


=Reference=
=Reference=
<references/>
<references/>

Latest revision as of 01:12, 22 September 2012

Unit-Testing Frameworks for Ruby: Cucumber

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber .

Introduction

Unit testing <ref>Unit Testing in Ruby</ref> is a software development process for testing individual units of source code independently for proper operation <ref>Unit Testing</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>Ruby Unit Testing Framework</ref>. Other testing frameworks available for Ruby are Shoulda, RSpec and Cucumber.

Cucumber

Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

Behaviour Driven Development(BDD)

Behaviour Driven Development<ref>BDD</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non-programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

Acceptance Test

Acceptance Test<ref>Acceptance Test</ref><ref>Cucumber Book</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

Cucumber Acceptance Test

     Feature: Sign up
     Sign up should be quick and friendly.
Scenario: Successful sign up New users should get a confirmation email and be greeted personally by the site once signed in. Given I have chosen to sign up When I sign up with valid details Then I should receive a confirmation email And I should see a personalized greeting message
Scenario: Duplicate email Where someone tries to create an account for an email address that already exists. Given I have chosen to sign up But I enter an email address that has already registered Then I should be told that the email is already registered And I should be offered the option to recover my password


Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

How Cucumber works

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

Feature

A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

Scenario

A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions)
2. When : Steps that represent the event.
3. Then : Steps that represent the expected outcome.
4. And and But : Steps that extend the previous step.

Step and Step Definitions

When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>Step Definitions in Ruby</ref>

Successful steps

When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green).

Undefined steps

When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

Pending steps

When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

Failed steps

When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows :

1. Green : for passing.
2. Yellow : for not yet implemented.
3. Red : for failing.
4. Blue : Once a step fails all the successive steps are marked in blue.

Cucumber Testing Stack

Advantages of Cucumber

  • Specifications can be written in more than forty different spoken languages.
  • Cucumber helps reduce the gap between technical and non-technical members of a software team.
  • Cucumber tests can be easily read and written by business stakeholders.
  • Writing Cucumber tests are quick, easy, efficient and understandable.

Cucumber Installation

To install cucumber<ref>Installing Cucumber</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

    gem install cucumber 

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

    cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

    gem install rspec

Testing a Sample Ruby Application using Cucumber

Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>Sample Cucumber Application</ref>.

Step 1 : Create a new directory

    mkdir HelloCucumber 

Step 2 : Install Cucumber and Rspec

    gem install cucumber 
    gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

     mkdir features

Content of features/basic.feature

    Feature: Hello World Feature
Scenario: Hello World Scenario Given The Action is Hello When The Subject is World Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

     mkdir features/step_definitions


The directory structure looks like this

Directory structure


Content of features/step_definitions/basic_step.rb

     require 'rspec/expectations'
Given /The Action is ([A-z]*)/ do |action| @action = action end
When /The Subject is ([A-z]*)/ do |subject| @subject = subject end
Then /The Greeting is (.*)/ do |greeting| greeting.should == "#{@action}, #{@subject}" end

Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.


Step 5: Running cucumber command you will see the following output

    Feature: Hello World Feature
Scenario: Hello World Scenario # features\basic.feature:3 Given The Action is Hello # features/step_definitions/basic_steps.rb:3 When The Subject is World # features/step_definitions/basic_steps.rb:7 Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
1 scenario (1 passed) 3 steps (3 passed) 0m0.016s Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

    Feature: Hello World Feature
Scenario: Hello World Scenario Given The Action is Hello When The Subject is World Then The Greeting is Hello, World
Scenario: Bye World Scenario Given The Action is Bye When The Subject is World Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

   Scenario: Hello World Scenario      # features\basic.feature:3
   Given The Action is Hello         # features/step_definitions/basic_steps.rb:3
   When The Subject is World         # features/step_definitions/basic_steps.rb:7
   Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
Scenario: Bye World Scenario # features\basic.feature:8 Given The Action is Bye # features/step_definitions/basic_steps.rb:3 When The Subject is World # features/step_definitions/basic_steps.rb:7 Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 expected: "Bye, World" got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError) ./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/' features\basic.feature:11:in `Then The Greeting is Hello, World'
Failing Scenarios: cucumber features\basic.feature:8 # Scenario: Bye World Scenario
2 scenarios (1 failed, 1 passed) 6 steps (1 failed, 5 passed) 0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

Testing a Sample Rails Application using Cucumber

Cucumber<ref>Sample Cucumber Application on Rails</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.

   rails new cucumber_app

Install the required cucumber gems

   gem install cucumber
   gem install cucumber cucumber-rails 

Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.

   group :test do
      gem 'database_cleaner'
      gem 'cucumber'
      gem "rspec-rails", "~> 2.0", :require => false
      gem "cucumber-rails", "1.0.6"
      gem 'webrat'
   end

After modifying the gem file, run bundle update

     bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

   rails generate cucumber:install


    identical  script/cucumber
          chmod  script/cucumber
          exist  features/step_definitions
    identical  features/step_definitions/web_steps.rb
          exist  features/support
    identical  features/support/paths.rb
    identical  features/support/selectors.rb
    identical  features/support/env.rb
          exist  lib/tasks
    identical  lib/tasks/cucumber.rake


The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.

   rails generate model article title:string content:text 
   rake db:migrate
   rake db:test:clone
   rails generate controller articles index 


The above four commands generate models with the name article and with two fields title and content and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

   => cucumber

Capybara

<ref>Web-app with Cucumber and Capybara</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber

<ref>Book on Cucumber and RSpec</ref>

Rspec Shoulda Cucumber
RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design. Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development. Cucumber is a combination of Test Driven Development and Behaviour driven development.
RSpec provides a Domain Specific Language that can express code functionality and behaviour. Shoulda provides macros, helpers and matchers. Cucumber allows the test cases to be written in native languages.
RSpec too allows nested describe structure. Shoulda has nested contexts which helps create different environment for different set of tests. Cucumber is similar to RSpec and provides nested structures.
RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind. Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive. Cucumber is more descriptive and allows business stakeholder to read and write test specification.

Summary

Cucumber<ref>Advantage of Cucumber</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

Reference

<references/>