This power point presentation provides details on syntax of Gherkin language and how it can be used to write accurate user acceptance criteria for user stories.

1. Behavior Driven Development
With Cucumber and Gherkin
By – Arati Joshi

2. Audience
• Product Owners
• Business Owners
• Subject Matter Experts
• Business Analysts
• Testers
• Developers

3. What is Cucumber?
• Cucumber is framework designed specifically to help
business stakeholders get involved in writing
acceptance tests.
• It allows acceptance tests to be automated and the
acceptance tests to be “executed” against the system.
• It helps “bridging the communication gap between
domain experts and developers”.
• Each test case in Cucumber is called a scenario, and
scenarios are grouped into features.
• Each scenario contains several steps.
• Under the hood, step definitions translate from the
business-facing language(Gherkin) into Java code

4. What is an Acceptance Test?
• Validates that the ‘right’ system is being built
• Business/user/customer point of view
• Written in non-technical format
• Helps document what the system should do
• When automated, become “living
documentation”
• Shared team understanding of what’s being built
• Helps define what “done” means

5. What is Gherkin?
The business-facing parts of a Cucumber test suite, stored
in feature files, must be written according to syntax
rules—known as Gherkin—so that Cucumber can read
them.
Gherkin is –
• Business readable domain specific language
• Represents tests in natural language, not code
• Line-oriented
• Keywords(e.g. Feature, Scenario)
• Localized in 40+ spoken languages (French, Bulgarian,
Japanese etc.)

6. What we are going to discuss about?
• Feature
• Scenario
• Given, When, Then, And, But keywords
• Tags
• Comments
• Data Tables
• Scenario Outline
• Background
• pyStrings

7. Feature
• Start with “Feature: “ keyword
• Followed by feature name/terse description
• Optional free text description
Feature: Activate CAD/BOM Alignment functionality
In order to view the side by side report from the Wizard
As a valid AVBOM2 application user
I want an ability to set CAD BOM Effective Points for the AVBOM2 program in
the AVBOM2 application

8. Feature
In order to <meet some goal>
As a <type of stakeholder>
I want <a feature>
Example :-
Feature: View side by side report
In order to view side by side report from Wizard
As a valid AVBOM2 application user
I want an ability to set CAD BOM Effective point for AVBOM2 program in
AVBOM2 application
Value
centric

9. Feature
As a <type of stakeholder>
I want <a feature>
So that <some goal can be met>
Example :-
Feature: View side by side report
As a valid AVBOM2 application user
I want an ability to set CAD BOM Effective point for AVBOM2 program in
AVBOM2 application
So that I can view side by side report from Wizard
Role/person
centric

10. Scenario
• Concrete examples of expected system behavior
• Describes a particular situation
• Should be independent and isolated
• Can represent:
– Happy paths
– Error paths
• Start with “Scenario: “ keyword
• Followed by title
• Keep your scenarios short, and don’t have too
many, i.e., less than ???

11. Scenario Steps
Given When Then
Set up initial state Perform action(s) Check end state

12. Given
Purpose - To put the system in a known state before the user (or external
system) starts interacting with the system (in the When steps).Givens are like
preconditions in use cases.
Good practice – Avoid talking about user interaction in givens.
Example -
@FormValidation
Scenario: Check if valid program is selected for CAD BOM effective point selection
Given user is on the 'Activate CAD BOM Alignment screen'
When program is not selected
And the 'Save' button is clicked
Then screen should show an error stating
"""
Please select program first for effective point selection.
"""

13. When
Purpose - To describe the key action that the user performs.
Example -
@FormValidation
Scenario: Check if valid program is selected for CAD BOM effective point selection
Given user is on the 'Activate CAD BOM Alignment screen'
When program is not selected
And the 'Save' button is clicked
Then screen should show an error stating
"""
Please select program first for effective point selection.
"""

14. Then
Purpose - To observe outcomes
Good Practice - The observation should be related to business value/benefit
in your feature description. The observations should inspect output of the
system(a report, user interface, message, command output) and not
something which has no business value and instead part of implementation.
Example -
@FormValidation
Scenario: Check if valid program is selected for CAD BOM effective point selection
Given user is on the 'Activate CAD BOM Alignment screen'
When program is not selected
And the 'Save' button is clicked
Then screen should show an error stating
"""
Please select program first for effective point selection.
"""

15. And, But
Purpose - If you have several 'Given', 'When' or 'Then' steps then 'And' or
'But' could be used to read scenario more frequently.
Example -
@FormValidation
Scenario: Check if valid program is selected for CAD BOM effective point selection
Given user is on the 'Activate CAD BOM Alignment screen'
When program is not selected
And the 'Save' button is clicked
Then screen should show an error stating
"""
Please select program first for effective point selection.
""“
@AccessCheck
Scenario: Role check for user to be able to set the CAD BOM effective point for a program
Given role of the user is BOM Admin
Then user has 'Edit' access to 'Activate CAD BOM Alignment Screen'
But for all other roles user having 'Read Only' access to 'Activate CAD BOM Alignment Screen'

16. Tags
• Mark features and scenarios with arbitrary tags
• Map to unit test framework “categories”
• Scenarios “inherit” feature tags
• Can have multiple tags
• Tags specified using @
• @ignore is a special case
@AccessCheck
Scenario: Role check for user to be able to set the CAD BOM effective point for a
program
Given role of the user is BOM Admin
Then user has 'Edit' access to 'Activate CAD BOM Alignment
Screen'
But for all other roles user having 'Read Only' access to
‘Activate CAD BOM Alignment Screen'

17. Tags
• Possible uses:
– Group features into feature supersets
– Mark certain tests as @important
– Differentiate between @slow and @fast executing
tests
– Mark tests @wip
– Mark tests to be executed @weekly @daily
@hourly
– Mark tests as @humanexecuted

18. Comments
• Keywords in Cucumber can be preceded with
comments
• Comments allows user to provide details
about the ‘Feature’ or ‘Scenario’

19. Multiline Arguments - Data Tables
@Scenario: User logging in into AVBOM2 application is a valid AVBOM2 user
Given user has one of the roles given below
|UserRole |
|D & R Engineer |
|BOM Admin |
|CAD Designer |
|External Supplier |
Then user is a valid internal or external Ford Motor company user

20. Multiline Arguments - pyStrings
• Multiline Strings (also known as pyStrings) are handy for specifying larger piece of
text.
• Text should be offset by delimiters consisting of three double quote marks(“””) on
lines by themselves.
Example -
@FormValidation
Scenario: Check if valid program is selected for CAD BOM effective point selection
Given user is on the 'Activate CAD BOM Alignment screen'
When program is not selected
And the 'Save' button is clicked
Then screen should show an error stating
"""
Please select program first for effective point selection.
“””

21. Scenario Outline
@AccessCheck
Scenario Outline: User authorization to view 'Activate CAD BOM Alignment' link
Given user is valid internal or external Ford Motor Company user
And user has logged in to <Application Type>
And user has <User Role> role
Then user is able to view 'Activate CAD BOM Alignment' link
Examples:
|Application Type |User Role |
|AVBOM2 dashboard|Any |
|AVBOM2 portal |BOM Admin |

22. Background
• Provides context(state setup) to the scenarios in a feature
• Execute before every scenario
• Don’t use Background to set up complicated state unless that state is
something the reader actually needs to know.
• Background section short. After all, you’re expecting the user to actually
remember this stuff when reading your scenarios.
Example:
Background: User logging in into AVBOM2 application is valid AVBOM2 user
Given user has one of the roles given below
|UserRole |
|D & R Engineer |
|BOM Admin |
|CAD Designer |
|External Supplier |
Then user is valid internal or external Ford Motor company user

23. Summary
We learned about Gherkin language syntax:-
• Feature
• Scenario
• Given, When, Then, And, But keywords
• Tags
• Comments
• Data Tables
• pyStrings
• Scenario Outline
• Background