Cucumber is a software tool that computer programmers use for testing other software. It runs automated acceptance tests written in a behaviour-driven development (BDD) style. Cucumber is written in the Ruby programming language.Cucumber is Aslak Hellesoy's rewrite of RSpec's "Story runner"(In April 2008), which was originally written by Dan North.

Cucumber is a tool which facilitate BDD.Cucumber is not a Browser Automation tool, but it works well with Browser Automation tools such as Selenium Web driver

One of the least Technical toolsA very active open source projectSupports a variety of languages

ProsBDD is Friendly & Understandable by Non Technical UserSupports Multiple Platform, OS and Different browsersAutomation framework based BDD Cucumber is not really hard to develop and maintenanceGreat ROIPredictability & Confidence

Cons- BDD is Friendly & Understandable by Non Technical User- Supports Multiple Platform, OS and Different browsers- Automation framework based BDD Cucumber is not really hard to develop and maintenance

Gherkin is the format for Cucumber Specifications. Technically speaking it is line based language with a well-defined syntax, but it’s so simple that you don’t have to know how to program in order to use it. Gherkin Syntax:

Feature: SummaryScenario: TitleGiven [Some Initial Context- Past tense]When [An event occurs - Present tense]Then [Ensures some outcome - Future Tense]

Gherkin documents are stored in regular text files with a .feature file extension.

When you run Cucumber, it will generate a report that verifies whether or not the software behaves the way the Gherkin document says.

Testers can write some code that translates the text in the Gherkin document into interactions with the software.

- Feature- Background- Scenario- Given- When- Then- And- But- *- Scenario Outline- Examples

FeatureEach Gherkin file begins with the Feature keyword. This keyword doesn’t really affect the behaviour of your Cucumber tests at all; it just gives you a convenient place to put some summary documentation about the group of tests that follow.In valid Gherkin, a Feature must be followed by one of the following: • Scenario • Background • Scenario Outline

ScenarioTo actually express the behaviour we want, each feature contains several scenarios. Each scenario is a single concrete example of how the system should behave in a particular situation. If you add together the behaviour defined by all of the scenarios, that’s the expected behaviour of the feature itself.

Given, When, ThenIn Gherkin, we use the keywords Given, When, and Then to identify those three different parts of the scenario:

Scenario: Successful withdrawal from an account in creditGiven I have $100 in my account # the contextWhen I request $20 # the event(s)Then $20 should be dispensed # the outcome(s)

So, we use Given to set up the context where the scenario happens, When tointeract with the system somehow, and Then to check that the outcome of thatinteraction was what we expected

And , ButEach of the lines in a scenario is known as a step. We can add more steps to each Given, When, or Then section of the scenario using the keywords And and But

Scenario: Attempt withdrawal using stolen cardGiven I have $100 in my accountBut my card is invalidWhen I request $50Then my card should not be returnedAnd I should be told to contact the bank

Cucumber doesn’t actually care which of these keywords you use; the choice is simply there to help you create the most readable scenario.

https://cukes.info/

http://www.slideshare.net/kmstechnology

http://www.slideshare.net/alan_parkinson

http://chrismdp.com/2013/01/bdd-is-not-cucumber/