Gherkin is a business readable DSL that lets you describe software behaviour without detailing how that behaviour is implemented.

Syntax

• line oriented and uses indentation to define structure
• parses:
  • Features
  • Scenarios
  • Steps

Feature

• describes the background, scenario outline and examples
• contains a list of scenarios.

Scenario

• 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.
• eg.
  • Given I have 93 cucumbers in my belly

Step Definition

• 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.

And, But

• same kind of steps as all the other. It is just added for readability.

  Scenario: Multiple Givens
    Given one thing
    Given another thing
    Given yet another thing
    When I open my eyes
    Then I see something
    Then I don't see something else.

  Scenario: Multiple Givens
    Given one thing
    And another thing
    And yet another thing
    When I open my eyes
    Then I see something
    But I don't see something else.

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.

User Story:

• As a [role] I want [feature] so that [benefit]

Acceptance Criteria:

• Given [initial context], when [event occurs], then [ensure some outcomes].

Behavioural Specification

Each user story, in some way, should follow the following structure.

Title:

• story should have a clear explicit title.

Narrative:

• 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.

Acceptance Criteria:

• 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.