This [[

1. for
Automated Acceptance Testing

2. What is Acceptance Testing ?
● We call them acceptance tests because they express what the software
needs to do in order for the stakeholder to find it acceptable.
● These tests are different from unit tests, which are aimed at developers and
help them to drive out and check their software designs.
● Acceptance tests more aligned with requirements specification which is
derived from the stakeholder’s requirements
“Unit tests ensure you build the thing right, while Acceptance tests ensure you
build the right thing”

3. How Cucumber Works
Your Project
Features
Scenarios
Steps
Step Definitions
Support Code
Automation Library
Your System
Business facing
Technology
facing

4. Gherkin
Gherkin is the language that Cucumber
understands.
It is a Business Readable, Domain Specific
Language that lets you describe behaviour of the
software without detailing how that behaviour is
implemented.
● It's a line-oriented language that uses
indentation to define structure.
● Line endings terminate statements (eg,
steps).
● Either spaces or tabs may be used for
indentation
● Most lines start with a keyword.
● Comment lines are allowed anywhere in
the file and begin with a hash sign (#)
and some amount of text.
● The parser divides the input into
features, scenarios and steps.
● When you run the feature the trailing
portion (after the keyword) of each step
is matched to a code block called Step
Definitions.

5. Fundamentals in Gherkin syntax
Feature
● A .feature file is supposed to describe a single feature of the system.
● It's just a way to provide a high-level description of a software feature, and to group
related scenarios.
Feature: Account Holder withdraws cash
Scenario: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned

6. Cont.
Scenario
● To actually express the behavior 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 behavior defined by all of the scenarios, that’s the expected
behavior of the feature itself
Steps
● A step typically starts with Given, When or Then. If there are multiple Given or When
steps underneath each other, you can use And or But.
● Cucumber does not differentiate between the keywords, but choosing the right one is
important for the readability of the scenario as a whole.

7. Cont.
Given to set up the context where the scenario happens,
When to interact with the system (i.e. Calling the API)
Then to check that the outcome of that interaction was what we expect
And, But
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 card
Given I have $100 in my account
But my card is invalid
When I request $50
Then my card should not be returned
And I should be told to contact the bank

8. Organizing tests
Background
● A background section in a feature file allows you to specify a set of steps that are
common to every scenario in the file.
● Instead of having to repeat those steps over and over for each scenario, just move them
into a Background element.
Advantages:
● If you ever need to change those steps, you have to change them in only
one place.
● The importance of those steps fades into the background so that when
you’re reading each individual scenario, you can focus on what is unique
and important about that scenario.

9. Cont.
Background Example:

10. Cont.
Scenario Outline
● When you have a complex business rule with several variable inputs or outputs you
might end up creating several scenarios that only differ by their values.
● A Scenario Outline section is always followed by one or more Examples sections, which
are a container for a table.
● The table must have a header row corresponding to the variables in the Scenario Outline
steps.
● Each of the rows below will create a new Scenario, filling in the variable values.

11. Cont.
Scenario Outline Example:

12. Cont.
Tags
● Tag is a way to group Scenarios.
● They are @ prefixed strings and you can place as many tags as you like above Feature, Scenario,
Scenario Outline or Examples keywords.
● Tags are inherited from parent elements. For example, if you place a tag above a Feature, all
scenarios in that feature will get that tag.
● You can tell Cucumber to only run scenarios with certain tags, or to exclude scenarios with certain
tags.
● If you want to skip some tests from executing, then use ~ with tag name.

13. Cont.
Tags Example:

14. Step Definitions
● When Cucumber executes a Step in a Scenario it will look for a matching Step Definition to
execute.
● A Step Definition is a small piece of code with a pattern attached to it.
● The pattern is used to link the step definition to all the matching Steps, and the code is what
Cucumber will execute when it sees a Gherkin Step.
● Java example:
● Step definition can be written in any language such as Ruby, Java, Python, C# (using SpecFlow), C++,
PHP (using Behat) etc. because Cucumber supported with almost all the popular languages.
● Installation and configurations will be specific to each language.
For more info: https://cucumber.io/docs

15. Framework integration
❖ Cucumber is not a Browser Automation tool, but it works well with Browser Automation tools such
as:
➢ Selenium Webdriver
➢ Capybara
➢ Watir
❖ Serenity - an open source reporting library that helps you write better structured, more
maintainable automated acceptance criteria, and also produces rich meaningful test reports.
(http://thucydides.info/docs/articles/an-introduction-to-serenity-bdd-with-cucumber.html)
Serenity not only reports on whether a test passes or fails, but documents what it did, in a step-by-
step narrative format that includes test data and screenshots for web tests.

16. Example reports