Acceptance Tests and GherkinPresenter: Stephanie Vineyard
User Stories
• Simple, clear, short description of customer valued functionality
• Representation rather than documentation
What’s A User Story?
Card Conversation Confirm
3 C’s of user stories
User Story Template
As a [type of user], I can [goal] so that
[value]
Title:
Notes:Assumptions:
Estimate:Constraints:
As a [type of user], I want [goal] so that
[value]
Title:
Notes:Assumptions:
Estimate:Constraints:
Priority:
Example
As a [type of user], I can [goal] so that [value]
Title:
Notes:Assumptions:
Estimate:Constraints:
As a coffee shop visitor, I can checkout using my credit card so that I can purchase a selected beverage.
Checkout Using Credit Card
Notes: Support mc, visa, amex
25
Constraint: Must use Chase payment service13 pts
Acceptance Criteria
As a [type of user], I can [goal] so that [value]
Title:
Notes:Assumptions:Constraints:
Test with valid mc, visa, amex passesTest with valid other cards failsTest with expired card failsTest with invalid cvv failsTest with invalid zip fails
Checkout Using Credit Card
Requirements using examples
The essence of building a program is debugging the specification.
Frederick Brooks (1987)
• Specification by Example• Executable Specifications• Scenarios• Automated Acceptance Tests (AAT)• Behavior Driven Development (BDD)• Acceptance Test Driven Development
(ATDD)• Gherkin Syntax
Common Terminology
Requirements using Examples
Elements of this Technique
Tooling
Documentation
Collaboration
18
Building in Quality
Plan Collaborate Deliver
Build the right thing
Build the thing right
Specify the right amount?
How it all relates
An Example of using an example…
gher·kinˈgərkin/noun1. a small variety of cucumber, or a young green cucumber used for pickling.
Gherkin
Business readable, domain specific language
• Given < situation >• When < action >• Then < expected result >
Gherkin syntax
25
Developing Examples
1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples
Background: You are developing an online ordering website for a local company that grows, harvests and sells botanicals directly to customers.Feature: Calculate customer order
Feature
1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples
Calculate Order Feature
Create a user story
User Story: As a customer, I want to review shipping costs in my shopping cart before checking out, so that I can see if I will receive free shipping.
User Story
Stakeholders can rank
Team can estimate
1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples
Collaborate
31
How do I describe what I want?
How do I validate that this work is done?
How do I code this
feature?
What are the details
of this feature?
1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples
Feature: Determine shipping rates
Scenario 1: Standard Shipping Rate
Scenario 2: Free Shipping Rate
Creating Acceptance Tests
32
1. Feature 2. User Story 3. Collaborate 4. Scenarios 5. Examples
Scenario: Standard Shipping RateGiven I am a customerAnd my order amount is $49.99When I view my cartThen I see that shipping costs are $3.99
Scenarios
Scenario: Free Shipping RateGiven I am a customerAnd my order amount is $50.00When I view my cartThen I see that shipping costs are $0.00
Scenario OutlinesFeature: Determine shipping rate
Scenario Outline: Standard shipping rate• Given that I am a customer• And my order amount is <order amount>• When I view my cart• Then I see that shipping costs are <shipping cost>
Examples: | order amount | shipping cost | $49.99 | $3.99 | $50.00 | $0.00 | $75.00 | $0.00
Create your acceptance tests
• Imperative– Descriptive– Step-by-step instructions– Heavier reliance on the user interface
• Declarative– Informative– Abstracts details– Limits reference to specific user interface
behavior
Gherkin Styles
Feature: Validate userScenario: User with valid credentials returns to orderImperative (Narrative)
Given I am an unauthenticated userAnd I am on the login pageAnd I enter a valid name in the Name fieldAnd I enter the corresponding password in the Password fieldWhen I select the Login buttonThen I should see the welcome page
Imperative Style
Implementation Detail – what if decide to use Token-based authentication or single sign-on?
UI Detail – what if the user interface changes and you select name from a drop-down list or select a radio button?
Feature: Validate userScenario: User with valid credentials returns to orderDeclarative (Informative)
Given I am an unauthenticated userAnd I am on the login pageWhen I submit valid credentialsThen I should see the welcome page
Declarative Style
Feature: Validate userScenario: User with valid credentials returns to order
Side-by-side Comparison
Imperative (Narrative) Declarative (Informative)Given I am an unauthenticated userAnd I am on the login pageAnd I enter a valid name in the Name fieldAnd I enter the corresponding password in the Password fieldWhen I select the Login buttonThen I should see the welcome page
Given I am an unauthenticated userAnd I am on the login page
When I submit valid credentialsThen I should see the welcome page
— If the user interface is constantly changing, it is better to use imperative.
— Declarative is easier to maintain.
— Developers prefer the imperative style.
— If a stakeholder is concerned about the user’s interaction experience, use imperative.
— Declarative specifies implementation details.
True or False?
F
T?T
F
Automated testing is an Agile practice
• Frequent and immediate feedback on software quality
• Courage and creativity
• Always delivering working software
Test automation
Path to automation
• Specification by Example by Gojko Adzic http://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084
• Writing Gherkin: http://behat.readthedocs.org/en/v2.5/guides/1.gherkin.html
• The Cucumber Book by Matt Wynne http://www.amazon.com/Cucumber-Book-Behaviour-Driven-Development-Programmers/dp/1934356808/ref=sr_1_1?s=books&ie=UTF8&qid=1421707079&sr=1-1&keywords=cucumber
Resources