The three main ‘key pieces’ of BDD: the artifacts, the domain language, and the process.

Artifacts

When people talk about BDD, they tend to focus on the artifacts. The artifacts are an innovative way of expressing requirements and tests at the same time, using Gherkin syntax, the use of given/when/then/and/but keywords to describe acceptance criteria.

Gherkin serves two purposes: (1) serving as project’s documentation and (2) automated tests (unit and/or functional/acceptance tests)

Gherkin is a line-oriented language like Yaml or Python. Each line is called “step” and starts with a keyword. Tabs or spaces are used for the indentation and any comment is preceded by a hashtag (#).

Feature: Title of the Scenario Given [Preconditions or Initial Context] When [Event or Trigger] Then [Expected output]

A simple Login behavior:

Feature: Login As a user I want to be able to login to the website using valid credentials So that I will be able to access the application

@ui @regression @smoke Scenario: Valid login for predefined user Given I am on the home page And I open the login screen And I enter valid login user and password When I click on Login button Then I should be logged in

@ui @regression @smoke Scenario Outline: Valid login for more users Given I am on the home page And I open the login screen And I enter login details '' and '' When I click on Login button Then I should be logged in with correct user

A Gherkin document has an extension (.feature) for writing the tests.

Once the team agrees on the text, a programmer or an automation tester can use some tools to transform the near-English text into stub functions.

Then, the programmers or automation testers fill in the step definitions. The scenarios use these functions/methods. Once a full reasonable set of steps exist, any member of the team, technical or non-technical, can create new scenarios. Creating a new scenario could be 80-100% reuse and 0-20% new code. Both tests, from the example above, will share common steps.

The artifacts are powerful as principle, but they don’t drive development without real process change.

Domain language

The domain language is the language of the business – customers, books, orders, catalogs, invoices, etc. We can think of orders, for example, as an object, with data like: order number, customer, due date, created date, items, and so on. Orders can also have actions, such as receive payment.

Combining domain language with the artifacts makes a powerful combination. The code will be more clear, shorter, and easier to reuse.

Process

The story template and Gherkin are the artifacts, the permanent record.

The process is a collaboration between development, test, and product owner, sometimes called the three amigos. The BDD process moves through three phases: discovery, formulation and automation. The acceptance criteria are transformed into acceptance tests that are later automated.

https://www.infoq.com/interviews/george-dinwiddie-three-amigos

The goal here is to: Improve first-time quality by building the right thing up-front Reduce misunderstandings between technical staff Express requirements in unambiguous terms

Simply stated, instead of one person working alone to create a given/when/then/and/but, the team comes together to discuss what the software will do.

These conversations create a shared understanding. All roles in development can contribute to the work. The programmer needs to understand what to build. The testers can ask powerful questions to make sure the behavior described matches the intent. The product owner, analyst, or business person can use the process as a second-check, to prevent building the wrong thing.

Benefits of BDD in Cucumber Framework

Focuses on defining ‘behavior’ rather than defining ‘tests’
Enhances communication among the members of a cross-functional product team
Helps reach a wider audience by the usage of non-technical language
Enables you to understand how the system should perform from the developer’s and customer’s perspective

The improvement in the quality of code results in reduced costs of maintenance and also minimizes the project’s associated risks

What is Cucumber Framework

Cucumber is used to execute automated acceptance tests written in the “Gherkin” language. Gherkin is a domain-specific language for behavior descriptions. Gherkin is business readable.
Cucumber test automation makes use of two important files – Feature file – Contains code written in Gherkin (plain English text) Step definition file – Contains the actual code written by the developer

Resource

455 Behavior Driven Development

anitsh / til

Cucumber Framework and BDD #966