Cucumber presentation

What is Cucumber?
 Cucumber is a testing approach which supports
Behavior Driven Development(BDD). It explains the
behavior of the application in the simple English text
using “Gherkin” language.
 Cucumber is a tool that supports Behavior Driven
Development(BDD).It offers a way to write tests that
anybody can understand, regardless of their technical
knowledge.

 Cucumber reads executable specifications written in
plain text and validates that the software does what
those specifications say. The specifications consists of
multiple examples, or scenarios
 Each scenario is a list of steps for Cucumber to work
through. Cucumber verifies that the software conforms
with the specification and generates a report
indicating ✅ success or ❌ failure for each scenario.

Advantages of Cucumber
 It is helpful to involve business stakeholders who can’t
easily read code.
 Cucumber Testing focuses on end-user experience.
 Style of writing tests allow for easier reuse of code in
the tests.
 Quick and easy setup and execution.

Install and download the Cucumber
 To install Cucumber open command prompt on your
machine and type the following command:
 “gem install cucumber”. The version vary depending on
the latest.
 Install bundler(is used to install gems in bundles)
 We also have options to download Cucumber in
Eclipse IDE and intelli J.

Gherkins
 Gherkins uses a set of special keyword to give structure
and meaning to executable specifications. Each
keyword is translated to many spoken languages; in
this reference we use “English”.
 Most lines in a Gherkin document start with one of the
keywords.
 In order for Cucumber to understand the scenarios,
they must follow some basic syntax rules, called
Gherkin.

Gherkin serves multiple purpose
 Unambiguous executable specification
 Automated testing using Cucumber
 Document how the system actually behaves

 Gherkin documents are stored in .feature text files and
are typically versioned in source control system like
Git,SVN.
Step Conditions
 Step definitions connect Gherkin steps to
programming code. A step definition carries out the
action that should be performed by the step. So step
definitions hard-wire the specification to the
implementation.

Steps in Gherkin--> matched with-->
Step Conditions-->manipulates-->System
Step definitions can be written in many programming
languages. Here is an example using JavaScript:
When("{maker} starts a game", function(maker) {
maker.startGameWithWord({ word: "whale" })
})

 A Step Definition is a Java method with an expression
that links it to one or more Gherkin steps. When
Cucumber executes a Gherkin step in a scenario, it will
look for a matching step definition to execute.
Expressions
 A step definition’s expression can either be a Regular
Expression or a Cucumber Expression. The examples in
this section use Cucumber Expressions. If you prefer to
use Regular Expressions, each capture group from the
match will be passed as arguments to the step
definition’s method.

The primary Keywords are
 Feature
 Scenario Outline / Scenario
 Steps: Given,When,Then,And and But
 Gherkin is localised for many spoken languages, each
has their own localised equivalent of these keywords.

Examples follow this pattern
 Describe an initial context (Given steps)
 Describe an event (When steps)
 Describe an expected outcome (Then steps)

Gherkin Keywords
Given
 Given steps are used to describe the initial context of
the system - the scene of the scenario. It is typically
something that happened in the past.
 When Cucumber executes a Given step, it will
configure the system to be in a well-defined state, such
as creating and configuring objects or adding data to a
test database.

Given
 The purpose of Given steps is to put the system in a
known state before the user (or external system) starts
interacting with the system (in the When steps). Avoid
talking about user interaction in Given’s. If you were
creating use cases, Given’s would be your preconditions.
Examples
 Minne and mansi have started the game
 I am logged in
 Joe has a balance of Euros 45.

When
 When steps are used to describe an event, or an
action. This can be a person interacting with the
system, or it can be an event triggered by another
system. It’s strongly recommended you only have a
single When step per Scenario. If you feel compelled to
add more, it’s usually a sign that you should split the
scenario up into multiple scenarios.

When
Examples
 Guess a word
 Invite a friend
 Withdraw money

Then
 Then steps are used to describe an expected outcome,
or result.
 The step definition of a Then step should use an
assertion to compare the actual outcome (what the
system actually does) to the expected outcome (what
the step says the system is supposed to do).

 An outcome should be on an observable output. That
is, something that comes out of the system (report,
user interface, message), and not a behaviour deeply
buried inside the system (like a record in a database).
Examples
 See that the guessed word was wrong
 Receive an invitation
 Card should be swallowed

And,But
 If you have successive Given’s, When’s, or Then’s, you
could write
Example
 Multiple Givens
 Given one thing
 Given another thing

 Given yet another thing
 When I open my eyes
 Then I should see something
 Then I shouldn't see something else
 Or, you could make the example more fluidly
structured by replacing the successive Given’s, When’s,
or Then’s with And’s and But’s:

Background
 Occasionally you’ll find yourself repeating the same
Given steps in all of the scenarios in a feature.
 Since it is repeated in every scenario, this is an
indication that those steps are not essential to describe
the scenarios; they are incidental details. You can
literally move such Given steps to the background, by
grouping them under a Background section.

 A Background allows you to add some context to the
scenarios in the feature. It can contain one or more
Given steps.
 A Background is run before each scenario, but after
any Before hooks. In your feature file, put the
Background before the first Scenario.
 You can only have one set of Background steps per
feature. If you need different Background steps for
different scenarios, you’ll need to split them into
different feature files.

Scenario Outline
 The Scenario Outline keyword can be used to run the
same Scenario multiple times, with different
combinations of values.
 The keyword Scenario Template is a synonym of the
keyword Scenario Outline.

Scenario1: eat 5 out of 12
 Given there are 12 cucumbers
 When I eat 5 cucumbers
 Then I should have 7 cucumbers
Scenario 2: eat 5 out of 20
 Given there are 20 cucumbers
 When I eat 5 cucumbers
 Then I should have 15 cucumbers

 We can collapse these two similar scenarios into a
Scenario Outline.
 Scenario outlines allow us to more concisely express
these scenarios through the use of a template with <
>-delimited parameters:

Scenario Outline: eating
 Given there are <start> cucumbers
 When I eat <eat> cucumbers
 Then I should have <left> cucumbers
Examples:
 | start | eat | left |
 | 12 | 5 | 7 |
 | 20 | 5 | 15 |

 A Scenario Outline must contain an Examples (or
Scenarios) section. Its steps are interpreted as a
template which is never directly run. Instead, the
Scenario Outline is run once for each row in the
Examples section beneath it (not counting the first
header row).
 The steps can use <> delimited parameters that
reference headers in the examples table. Cucumber will
replace these parameters with values from the table
before it tries to match the step against a step
definition.

Doc Strings
 Doc Strings are handy for passing a larger piece of text
to a Step Definition.
Step Arguments
 In some cases, you might pass the more data to a
step,than fits on a single line. For this purpose,
Gherkins has “Doc Strings”,”Data tables”.

 In Cucumber, an example is called a scenario. Scenarios
are defined in .feature files, which are stored in
src/test/resources/hellocucumber directory (or a
subdirectory).
Feature: Is it Friday yet?
Everybody wants to know when it’s Friday
Scenario: Sunday isn’t Friday
 Given today is Sunday
 When I ask whether it’s Friday yet
 Then I should be told “Nope”

 The first line of this file starts with the keyword Feature:
followed by a name. It’s a good idea to use a name
similar to the file name.
 The second line is a brief description of the feature.
 The fourth line, Scenario: Sunday is not Friday is a
scenario, which is a concrete example illustrating how
the software should behave.

 The last three lines starting with Given, When and Then
are the steps of our scenario. This is what Cucumber
will execute.
@Given("today is Sunday")
public void today_is_Sunday() {
// Write code here that turns the phrase above into
concrete actions
throw new io.cucumber.java.PendingException();
}

@When("I ask whether it's Friday yet")
public void i_ask_whether_it_s_Friday_yet() {
concrete actions
}

@Then("I should be told {string}")
public void i_should_be_told(String string) {
concrete actions
}

Cucumber presentation

More Related Content

What's hot (20)

Similar to Cucumber presentation (20)

Recently uploaded (20)

Cucumber presentation