-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Gherkin; Given, When, Then steps to describe a process #2
Labels
Comments
johnsBeharry
added
planning
Project planning tools
documentation
Used to supplement someones' understanding
labels
Apr 23, 2019
This was referenced Jan 31, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Abstract
Communicating an idea is difficult. Issues arise for a variety of reasons; to name a few would be difference of culture, native language, skill level etc.
Gherkin is an action oriented framework to describe a processes using the constraint of Given, When, Then at the beginning of each step.
Motivation
By adopting a fixed structure of describing things, and aiming to remove ambiguity by being explicit we can communicate our ideas more precisely — leading to less arguments, misunderstandings and inefficient use of time spent translating meaning.
The structure we use is Gherkin. It is an action oriented language that is used to take business requirements and explain them in a way that is clear and without ambiguity.
The Golden Gherkin Rule:
Ambiguity in product requirements, or any form of communication around technology is very common and leads to wastage, and frustration by both the reporter of the task/bug/feature and the developer implementing the work.
The basic principal is that you define some process as a set of scenarios. The scenarios are sentences or "steps" beginning with Given, When, Then. But please note the Cardinal Rule of BDD: One Scenario, One Behavior!
Step types are meant to be guides for writing good behavior scenarios.
Specification
Gherkin
"And" can be used to extend the context, action or outcome.
By breaking down functionality into scenarios, you describe exactly the behavior / process you expect -- developers, designers whomever is implementing the work can make the functionality match.
Simple rule: be direct, and avoid ambiguity - if one of the steps can have multiple interpretations, you've done it wrong. Also, try and write steps in a way that they can be reused. This comes in very handy for larger projects with repetitive actions.
Features
Example
Scenarios
X
these steps happen.Steps: Given, When, Then
Given
some precondition that sets up the environmentWhen
an actionThen
an outcomeAnd
more criteria, can be applied after any of the Given, When, Then steps to extend their criteriaN.B - Givens should always use present perfect tense, and Whens and Thens should always use present tense.
Rationale
...
The text was updated successfully, but these errors were encountered: