Gherkin in Software Testing

Gherkin

                   

Gherkin is a domain-specific language used in Behaviour Driven Development to describe the business behaviour that should be modeled by the software being developed.

Behavior-Driven Development (BDD) has taken the software development world by storm – bringing Product, Development, and QA stakeholders together to ensure effective communication. The end result is a streamlined process that yields better results: features that customers actually need, higher quality products, and less time fixing issues later in the cycle.

Many teams practicing BDD use the Gherkin (“Given-When-Then”) format, which is written in plain-English, making it easy to understand regardless of technical expertise. Gherkin scenarios can easily run as automated tests using a tool like Cucumber, making descriptive reporting after automation test runs easy to share.

Gherkin is a plain text language that uses keywords, indentation and formatting to describe software specifications in terms of features, scenarios and steps.

Definitions for these components are written in a .feature file. Each .feature file should contain just one feature definition, followed by one or more scenarios. Each scenario has a number of steps explained using a Given-When-Then structure.

Use of Gherkin

There are many good reasons to use Gherkin. Possibly the three most important are:

1. It encourages teams to write and maintain ‘living documentation’, avoiding the typical pattern of: write documents, forget about them, write tests, forget about them.
2.  It can be used as the driver and foundation for your automated tests, helping to build a positive feedback loop between documentation, application development, test development and execution, and status reporting.
3.  It acts as a language bridge between business users, developers and testers, who should all be able to understand what has been explained in the documentation.

Gherkin provides a framework we can use to define what the end-user should expect from the features we’re developing, written in a way that everyone in the team can understand. These expectations should be defined clearly with detailed examples that leave no ambiguity regarding the acceptance criteria required by the business user to validate the end product.

What is a Feature

A feature file begins with the title of the feature introduced by the keyword “Feature:” followed by a short description of what the feature should do. Note that this text is usually not processed by any tools downstream and is generally used to convey information to the business users, developers and testers.

It’s important to understand that the description following the title should focus on the value of the feature to the business and the benefits it will deliver to the business end-users. It should not include any information about the implementation of lower-level functionality. Think of it as answering the questions “Who is this for?” and “Why should they want it?”

The aim is to have just one feature defined per feature file, so you’ll end up with many small files rather than a few large ones. This way it will be easier to process and organise these files downstream as features are implemented.

What is a Scenario

Next in the feature file comes the scenario definition. Each feature may have many scenarios. The title is demarcated by the keyword “Scenario:”. You have the option of writing a short description of the scenario after the title and before the first “Given:” statement. This description is sometimes called the ‘scenario brief’.

Scenarios should capture the users’ interaction with the system and the expectations they should have for the feature. However, to explain a feature fully usually requires many scenarios in order to account for all the possible permutations of use cases.

The details of the scenario’s starting point, actions and completion point are defined in the form of ‘steps’.

3 Steps in Gherkin

                         

Each scenario is made up of a number of steps. The starting point is indicated by the keyword “Given:”, the actions that are completed are indicated by “When:”, and the keyword “Then:” introduces the expected outcome or completion point. This Given-When-Then construct is the backbone of the Gherkin language.

1. Given Steps

The ‘Given’ statement sets the context for the scenario – the known state that needs to be set up before the scenario is executed. It’s important to get the starting point correct because the automated tests being driven from the feature files depend on the system under test being in the correct state before the test steps are executed. 

The purpose of the Given step is to define the known state in enough detail for the automated tests to run reliably. No assumptions should be made and no Given statements should be left out.

2. When Steps

The ‘When’ steps define the actions performed by the feature and the events that take place as a result. In the automated testing domain, the When steps are the test steps that need to be executed. These will be interpreted by the test automation tool to be run as test actions to simulate the end user’s interactions with the software.

3. Then Steps

The ‘Then’ steps define the expected state of the system after the ‘When’ steps have been completed. In our case, they are the expected test results. These statements should describe the conditions that the user would see. Because we’re following BDD principles, acceptance criteria should be expressed from the perspective of the business or end-user.

Use of Gherkin in Automating Tests

One of our main reasons for using Gherkin is to facilitate automated testing. The .feature files containing the application use case scenarios can be used as inputs to your automated testing system. A scenario can be turned into a test that will be used to verify the delivered feature against its acceptance criteria.

If the acceptance test fails, then either the acceptance criteria are incorrect and need updating, or the software does not correctly deliver the outcomes required of it. By implementing these acceptance tests as automated tests we can increase the speed of the feedback loop and provide the capability to run the tests frequently and on-demand.

Ref: www.automated-testing.com

Ref: smartbear.com