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?