Gherkin is a business readable DSL that lets you describe software behaviour without detailing how that behaviour is implemented.
- line oriented and uses indentation to define structure
- describes the background, scenario outline and examples
- contains a list of scenarios.
- list of steps
- Given, When, Then, But, And (Cucumber treats them all the same but you shouldn’t)
Step: defined in .feature files
- each step needs a step definition that matches.
- equivelent to a method invocation with parameters.
- Given I have 93 cucumbers in my belly
- is a method definition
- /^I have (.*) cucumbers in my belly $/
- / # regex start/end
- ^ # start of match
- (.*) # first capture group
- $ # end of match
Given When Then
Given: Put the system in a known state.
- Avoid talking about user interactions in givens.
- You can use Given’s with a multiline table argument.
When: Describe the key action
- some action with an observable effect.
- eg. Interact with a web page, interact with UI.
Then: Observe Outcomes
- related to the business value/benefit in your feature.
- observation should be on some kind of output.
- something that comes out of the system.
- resist steps that just look in the database.
- verify outcome that is observable for the user.
- same kind of steps as all the other. It is just added for readability.
Given, When, Then: State Machine (Finite State Machine)
- Given: current state
- When: event or stimulus to that system.
- Then: describes resulting state of the system.
Better language to describe automated requirements, we will improve the way we think about those requirements, and therefore write better requirements. - Uncle Bob
The best way to describe the requirements of a system is to describe it as a Turing Machine. - Uncle Bob
Behaviour Driven Development (BDD)
Specialized version of TDD which focuses on behavioural specifications of software units.
- As a [role] I want [feature] so that [benefit]
- Given [initial context], when [event occurs], then [ensure some outcomes].
Each user story, in some way, should follow the following structure.
- story should have a clear explicit title.
- Short introductory section that specifies:
- who is the driver, stakeholder of the story.
- which effect the stakeholder wants the story to have.
- what business value the stakeholder will derive from this effect.
- Description of each specific case of the narrative.
- Specify the initial condition.
- Which event triggers the start of the scenario.
- It states the expected outcome.
Scenario’s are ideally phrased declaratively rather than imperatively in the business language with no reference to elements of the UI through which the interactions take place.
BDD caters to the idea of specification as a ubiquitous language.