#Gherkin
Wspólny język projektu
About ME
- mentor & consultant
- devThursday keeper
Contact me:
in/paweł-radzikowski
paw.radzikowski@gmail.com
@
Paweł Radzikowski
Señor Developer @
Self-proclaimed code magician
BDD - Behavior Driven Development
Unit Tests for business processes
BDD - Behavior Driven Development
- The basis of the process is the creation of requirements
- Process description is understandable for client, analitics and programmers
- Automation
© G.Renee Guzlas
Image comes from emojidex.com
We would offer 10% discount for first orderto encourage new users
function
testGrantInitialOrderDiscount()
{...}
Discussion of acceptance criteria
Register as "Anna"
Go to "/catalog/search"
Click "Add to Cart"
[...]
- Hard to maintain
- Multiple definitions
- High entry threshold
Image comes from emojidex.com
Gherkin
Language of the project
Given the user has not ordered yet
When the user adds a book with the price of EUR 37.5 into the shopping cart
Then the shopping cart sub-total is EUR 33.75
Gherkin
- Non-technical language for business
- Describe system behaviour
- Bridge between business and programmer
Story Syntax
- Line-oriented
- Narration
- Acceptance criteria
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...Narration
- Describe feature (what to do)
- Describe who is the actor
- May describe what is the advantage
Feature: Serve coffee
In order to earn money
Customers should be able to
buy coffee at all times
Scenario: Buy last coffee
Acceptance Criteria
Main words:
- Given
- When
- Then
Scenario: Buy last coffee
Given there are 1 coffees left in the machine
And I have deposited 1 dollar
When I press the coffee button
Then I should be served a coffeeThe feature scenario
Other:
- Words: And, But, Exampes
- tables
- tags
Acceptance Criteria
@coffe @test
Feature: Serve coffee
In order to earn money
Customers should be able to
buy coffee at all times
@positive
Scenario: Buy last coffee
Given there are <start> coffees left in the machine
And I have deposited <money> dollar
When I press the coffee button
Then I should be served a coffee
And There are <left> coffees left in the machine
Examples:
| start | money | left |
| 1 | 5 | 0 |
| 2 | 2 | 1 |Story- Building steps
- Step should be generic
- Step should be understable
- Step should contain information about what to do
- Step should be written in correct English
- Steps should be consistent with each other (the way of building sentences)
Pros
For All:
- living documentation
- collaboration, early discovery of unknowns
- enforce building domain vocabulary and semi formal language (DSL) to express system behaviour consistently within the organization.
Pros
For devs:
- like TDD, it helps to think in chunks, create nice and testable code.
- write code for what is needed only (build the right thing)
- better coordination between different dev teams developing similar features with different technologies.
Pros
For QA:
- ready acceptance criteria
- ready building blocks for all kind of tests
- test what is exactly need (test the right thing)
Pros
For Product Owner:
- think and reason features in detail thus produce better specification
- better visual and coordination with other Managers and Product owners
- better visual and understanding on Devs and QAs output/report due to the same source/format of specs
Cons?
- Team can consider it as a waste of time
- Antitype by developers the concept of "Testing"
- The test can be targeted on verification of classes and methods and not on what the code really should do
Q&A ?
Copy of Gherkin: a language of the project
By Paweł Radzikowski
