User:Ashwin Bharadwaj Lakshmi Venkataramanan/sandbox

Cucumber
Developer(s)Aslak Hellesøy,[1] Joseph Wilk,[2] Matt Wynne,[3] Gregory Hnatiuk,[4] Mike Sassak[5]
Stable release
1.3.15 / May 9, 2014
Written inRuby
Operating systemCross-platform
TypeBehavior driven development framework / Test tool
LicenseMIT License
Websitecucumber.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.[7][8] 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.[9] Cucumber allows the execution of feature documentation written in business-facing text.

History

edit

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.[10]

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

edit

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

edit

Feature

edit

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

edit

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

edit

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

edit

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

edit

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

edit

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

edit

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 [11]

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

edit

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.[12]

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

edit

A feature definition, with a single scenario:[13]

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":[14]

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

edit

Cucumber reports the results in different formats using different plugins. The currently available plugins include

Other Languages

edit

Cucumber is also implemented in other languages besides Ruby.

See also

edit

References

edit
  1. ^ "Aslak Hellesøy". Aslakhellesoy.com. Retrieved 2012-01-24.
  2. ^ "Joseph Wilk | on AI, The Web, Usability, Testing & Software process". Blog.josephwilk.net. Retrieved 2012-01-24.
  3. ^ "Tea-Driven Development". Blog.mattwynne.net. Retrieved 2012-01-24.
  4. ^ "ghnatiuk's Profile". GitHub. Retrieved 2012-01-24.
  5. ^ "msassak's Profile". GitHub. Retrieved 2012-01-24.
  6. ^ "cucumber | RubyGems.org | your community gem host". RubyGems.org. 2014-07-17. Retrieved 2014-07-21.
  7. ^ "The Pragmatic Bookshelf | The Cucumber Book". Pragprog.com. Retrieved 2012-01-24.
  8. ^ "The Pragmatic Bookshelf | The RSpec Book". Pragprog.com. 2010-12-02. Retrieved 2012-01-24.
  9. ^ Lawrence, Richard. "Cucumber". Retrieved 2012-04-16.
  10. ^ "Cucumber Official Site".
  11. ^ "Scenario Outline". Retrieved 2015-09-10.
  12. ^ "Step Definitions". Retrieved 2015-09-10.
  13. ^ aslakhellesoy (2012-01-15). "examples/i18n/en/features/division.feature at master from cucumber/cucumber". GitHub. Retrieved 2012-01-24.
  14. ^ aslakhellesoy (2012-01-15). "examples/i18n/en/features/step_definitons/calculator_steps.rb at master from cucumber/cucumber". GitHub. Retrieved 2012-01-24.
edit

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