GHERKINubiquitous language for automated acceptance testing

What’s Gherkin?

• an ubiquitous language fordevelopers and stakeholders

• aimed for automated acceptance tests

• it adheres to BDD

What’s BDD?Behavior Driven Development

1

23

Why Gherkin?

• write executable specifications• enforce a collaborative approach• force a specification format• serve as living documentation

The language

• support for multiple languages• small set of keywords:

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

Feature

• provide summary documentation• one feature per file• avoid long descriptions

Feature

Feature: feature titleIn order to <meet some goal>As a <type of stakeholder>I want <a feature>

Scenario

• describes how system should behave under a particular situation

• follows a common pattern: context, action, outcome

Scenario

Scenario: Successful withdrawal from an accountGiven I have $100 in my accountWhen I request $20Then my balance should be $80

context

outcome(s)action(s)

Scenario

Scenario: Attempt withdrawal using blocked PINGiven i have $100 in my accountBut my PIN is blockedWhen i withdraw $50Then my request should be refutedAnd i am forced to reset my PIN

context

outcome(s)

action(s)

Capturing values

• values passed to code as arguments

• string wrapped by double quotes• all of the numbers

Scenario: Request a new card

Given I’ve lost my “Visa”

When I request a new card at the “ACME” desk

And I specify a limit of $ 5000 bucks Then I should be asked for my account details

And I should be provided with a brand new card

Capturing values

Scenario tips

• must make sense to the “others”

• must be executed independently• must be deterministic

DRY strategies

• share common context

• avoid repeating scenarios• group similar data

• strength focus on key examples

Scenario: Change PIN successfully Given I have been issued a new card And I insert the card, entering the correct PIN When I choose “Change PIN” from the menu And I change the PIN to 9876 Then the system should remember my PIN is now 9876

Scenario: Try to change PIN to the same as before Given I have been issued a new card And I insert the card, entering the correct PIN When I choose "Change PIN” from the menu And I try to change the PIN to the original number Then I should see a warning message

Background

Background: Insert a newly issued card and sign in Given I have been issued a new card And I insert the card, entering the correct PIN And I choose “Change PIN” from the menu

Scenario: Change PIN successfully When I change the PIN to 9876 Then the system should remember my PIN is now 9876

Scenario: Try to change PIN to the same as before When I try to change the PIN to the original number Then I should see a warning message

Background

Background

• only one per feature file

• short is better• avoid setting complicated state

• stick with givens

Given a User “Michael Jackson” born on “August 29, 1958”

And a User “Elvis” born on “January 8, 1935”

And a User “John Lennon” born on “October 9, 1940”

Data tables

Given these Users: | name | date of birth |

| Michael Jackson | August 29, 1958 |

| Elvis | January 8, 1935 |

| John Lennon | October 9, 1940 |

Formattingspaces are

ignored

Data tables

Scenario: Withdraw fixed amount of $50 Given i have $500 in my account When i withdraw the fixed amount of $50 Then i should receive $50 cash And the balance of my account should be $450

Scenario: Withdraw fixed amount of $100 Given i have $500 in my account When i withdraw the fixed amount of $100 Then i should receive $100 cash And the balance of my account should be $400

Scenario Outline

Scenario Outline: Withdraw fixed amount Given i have <balance> in my account When i withdraw the fixed amount of <withdrawal> Then i should receive <received> cash And the balance of my account should be <remaining>

Examples: | balance | withdrawal | received | remaining | | $500 | $50 | $50 | $450 | | $500 | $100 | $100 | $400 |

As many casesas you need

Scenario Outline

Scenario Outline: Withdraw fixed amount Given i have <balance> in my account When i withdraw the fixed amount of <withdrawal> Then i should <outcome> And the balance of my account should be <remaining>

Examples: Successful withdrawal | balance | withdrawal | outcome | remaining | | $500 | $50 | receive $50 cash | $450 |

Examples: Attempt to withdraw too much | balance | withdrawal | outcome | remaining | | $100 | $200 | see an error message | $100 |

Key examples

Best practices

• fix flickering scenarios• guard from brittle features• speed up slow features• avoid bored stakeholders

Incidental details

Scenario: Check inbox Given a User “Dave” with password “password” And a User “Sue” with password “secret” And an email to “Dave” from “Sue” When i sign in as “Dave” with password “password” Then i should see 1 email from “Sue” in my inbox

Scenario: Check inbox Given i have received an email from “Sue” When i sign in Then i should see 1 email from “Sue” in my inbox

Incidental details

Imperative VS declarative

Scenario: Redirect user to requested page after logging in Given a User “dave” exists with password “secret” And i am not logged in When i navigate to the home page Then i am redirected to the login form When i fill in “Username” with “dave” And i fill in “Password” with “secret” And i press “Login” Then i should be on the home page

Scenario: Redirect user to requested page after logging in Given i am an unauthenticated User When i attempt to view some restricted content Then i am shown a login form When i authenticate with valid credentials Then i should be shown the restricted content

Imperative VS declarative

Who’s write Gherkin?Tester

DeveloperProductOwner

ubiquitous language for automated acceptance testing

Questions?