User:Ashwin Bharadwaj Lakshmi Venkataramanan/sandbox

Cucumber is a software tool that computer programmers use for testing other software. It runs automated acceptance tests written in a behavior-driven development (BDD) style. Cucumber is written in the Ruby programming language. Cucumber projects are available for other platforms beyond Ruby. Some use Ruby Cucumber with a bridge into the target language (e.g. cuke4php and cuke4lua). Others use the Gherkin parser but implement everything else in the target language. Cucumber allows the execution of feature documentation written in business-facing text.

History
Dan North created RBehave, a behavior-driven development (BDD)  framework for  Ruby  which was later written as  RSpec. David Chelimsky provided plain text support for RSpec as the User stories prior to that had to be written in Ruby. Nevertheless, there were design flaws and usability issues that persisted. Aslak Hellesoy started the Cucumber project in April 2008 to address these issues. He was joined by Joseph Wilk, Ben Mabey, Matt Wynne, Mike Sassak and Gegory Hnatiuk. This team successfully completed the project in December 2009.

Cucumber, since its inception has been prominently used in Ruby. But it has also found its place in other languages like Java,  .Net ,  JavaScript  etc. Cucumber is structured in such a way that it is easy to comprehend for the product users and still have some code left to be written by programmers. This makes Cucumber a middle ground between developers and product users and has been instrumental in it becoming a successful BDD testing tool.

Feature File
Cucumber executes a Feature file (File extension : .feature) which has executable specifications written in a Domain Specific Language, named Gherkin. Gherkin is written in plain English and has a minimal structure which has the potential to accommodate the various business rules in testing.

Feature
Feature, as the name suggests, is a means to describe a specific feature of the system. The feature is described in the form of User story and could have multiple related scenarios attached to it. For example, A feature for logging into a system could have the following scenarios : Each of these shall have a set of steps to be tested but then all of them fall under one single feature.
 * Logging in using email id
 * Logging in using phone number
 * Logging in using customer id

Scenario
Scenario gives a complete explanation of the rule under consideration through a set of Steps. A scenario could have multiple steps usually ranging between 3-8 steps. These steps illustrate the input, an action and the expected outcome for a rule by use of a few Step Keywords listed below.

Given
The Given step provides an idea about the initial setup of the setup and also details of the input for performing a test.The AND,OR keywords could be used to add multiple Given steps for the test.

When
The When step describes the action that might have to be taken on the initial context described in the Given step. Ideally, a Scenario has only one “When” keyword and if there is a requirement for more than one When keyword for a scenario it might require splitting into multiple scenarios.

Then
Then illustrates the outcome expected when an input is executed using a set of pre-conditions mentioned in the When step. It allows for checking whether the actual outcome is as expected and determines the success or failure of a test.

Background
The use of Background keyword reduces redundancy when we have to write the same Given steps for multiple scenarios. In such cases, we use background to cover the Given steps for all scenarios in a feature file.

Scenario Outline
Many a times the requirement of passing multiple inputs to a scenario arise and the task of writing scenarios for each of them is not a viable solution. Scenario Outline provides for better optimization here by allowing variables to be passed to the Scenario steps. This is followed by a tabular example of the inputs to be passed and the output expected. The following illustrates the use of Scenario Outline

Step Definitions
These help translate the plain text in the Feature file into actual executable actions. Cucumber looks for a Step Definition to execute while it is running through a specific Step in a Scenario. It contains a piece of code which matches the Step definition to the corresponding Steps in the Scenario using regular expressions. The code which generates these definitions is intuitive enough to understand the plain English used in describing a Feature. The generated code is executed by Cucumber upon encountering the Gherkin step. The following templates illustrate how a Step definition corresponds to the Scenario and its steps.

Example
A feature definition, with a single scenario:

The execution of the test implicit in the feature definition above requires the definition, using the Ruby language, of a few "steps":

Reports
Cucumber reports the results in different formats using different plugins. The currently available plugins include
 * HTML
 * JSON
 * Pretty
 * Progress
 * JUnit
 * Usage
 * Rerun

Other Languages
Cucumber is also implemented in other languages besides Ruby.
 * JRuby (using Cucumber-JVM)
 * Java
 * Groovy
 * Javascript
 * JavaScript (using Cucumber-JVM and Rhino)
 * Clojure
 * Gosu
 * Lua
 * .NET (using SpecFlow)
 * PHP (using Behat)
 * Jython
 * C++
 * Tcl