User:Ashwin Bharadwaj Lakshmi Venkataramanan/sandbox

Cucumber

Developer(s)	Aslak Hellesøy, Joseph Wilk, Matt Wynne, Gregory Hnatiuk, Mike Sassak
Stable release	1.3.15 / May 9, 2014
Written in	Ruby
Operating system	Cross-platform
Type	Behavior driven development framework / Test tool
License	MIT License
Website	cucumber.io

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.

Keywords

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 :

• Logging in using email id
• Logging in using phone number
• Logging in using customer id

Each of these shall have a set of steps to be tested but then all of them fall under one single feature.

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

Scenario Outline: feeding a suckler cow
  Given the cow weighs <weight> kg
  When we calculate the feeding requirements
  Then the energy should be <energy> MJ
  And the protein should be <protein> kg

  Examples:
    | weight | energy | protein |
    |    450 |  26500 |     215 |
    |    500 |  29500 |     245 |
    |    575 |  31500 |     255 |
    |    600 |  37000 |     305 |

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.

Scenario: Some cukes
  Given I have 48 cukes in my belly

Given(/I have (\d+) cukes in my belly/)  do |cukes|
  puts “Cukes : #{cukes}”
end

Example

A feature definition, with a single scenario:

Feature: Division
  In order to avoid silly mistakes
  Cashiers must be able to calculate a fraction

  Scenario: Regular numbers
    * I have entered 3 into the calculator
    * I press divide
    * I have entered 2 into the calculator
    * I press equal
    * The result should be 1.5 on the screen

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

Before do
  @calc = Calculator.new
end

After do
end

Given /I have entered (\d+) into the calculator/ do |n|
  @calc.push n.to_i
end

When /I press (\w+)/ do |op|
  @result = @calc.send op
end

Then /the result should be (.*) on the screen/ do |result|
  @result.should == result.to_f
end

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

See also

• RSpec
• User story
• Selenium_(Software)
• Squish GUI Tester (BDD GUI Testing Tool for JavaScript, Python, Perl, Ruby and Tcl)
• Concordion (Java framework)
• Behat (PHP framework)
• Jasmine (JavaScript framework)

External links

• Cucumber project
• At the Forge - Cucumber, by Reuven M. Lerner in the Linux Journal
• Agile 2009 - Aslak Hellesoy - Cucumber test framework, podcast by Bob Payne with Aslak Hellesøy
• Cucumber: The Latest in Ruby Testing, by Mike Gunderloy
• Specflow, Cucumber in .NET
• Behave, Python framework
• Cucumber-js, Javascript framework

Category:Software testing tools Category:Software using the MIT license