You may have heard of test automation, which is the practice of automatically running tests, managing test data, and using the results to improve software quality.

Similarly, cucumber is a testing tool in a Behavior Driven Development (BDD) framework.

Behavior Driven Development (BDD)

BDD is a development process that originates from Test Driven Development (TDD), where product owners write scenarios or acceptance tests before developers write the codes.

Here is an illustration showing the conventional development process:

In Behavior Driven Development, creating test scripts from the developer’s and customer’s perspective became easy. In the first phase, developers, project managers, Quality Assurance (QA) team, user acceptance testers, and the product owner will discuss and brainstorm test scenarios to call a software or application successful. And this necessitated the origin of Gherkins, as these people do not belong to the same community. 

Gherkin is a plain English text language that helps the test automatioCucumber testing tool interpret and execute the test on the software/application.

The common set of keywords found in English text is available in Gherkin. People from different communities can use it and get the same output as test scripts.

Also, Gherkin supports many other native languages, such as French, Finnish, Indonesian, Hungarian, Hindi, Urdu, and Gujarati, apart from English.

We can easily read and understand the test automation functional validation in Cucumber. It provides documentation, automated tests, and development aid. In the earlier stage, developers implemented Cucumber in Ruby and later in the Java framework.

How Does it Function

Once the code gets ready, test scripts are ready too. The code needs to pass the BDD test scripts. In case it does not, we need code refactoring.

Cucumber reads the plain-English code contained in the feature file. (A feature is an independent functionality of the product under test).

The code to be executed can be different software frameworks such as Ruby on Rails, Selenium, and many more. Every BDD framework tool does not support every tool.

Benefits of Cucumber Test Automation Tool Over Others

• Cucumber supports several languages like Java, Ruby and .net.
• It serves as a bridge between technical and business language. You can create a test case in plain English text.
• It facilitates writing the test script without knowing any code. And for this reason, it allows the involvement of non-programmers as well.
• It enables an end-to-end test framework, unlike other tools.
• Code reusability is possible in Cucumber test automation due to its simple script architecture.

Files in Cucumber:

1. Feature file: In this, we write the Features to be tested in Gherkin format- Given/When/Then. You can also run the feature file to execute the test scripts written in the Step definition file.

2. Step definition file: As and when the Feature file is ready, each sentence of the Feature file can be further implemented over the Step definition file.

3. Runner File: By using the feature file. This file runs the test script written over the Step definition file.

Feature Files

Feature files are a key component in the Cucumber testing tool for writing acceptance steps. It is recommended to have a separate feature file for each feature under test. The feature file should have the extension “.feature”.
The following terms, segments, or parts make up a basic feature file:
• Feature – The name of the feature under test
• Description (optional) − Describes feature under test
• Scenario – Deals with the test scenario
• Given – is the prerequisite before the test steps getting executed
• When − Specific condition which should match to execute the next step
• Then − What would happen if the condition mentioned in WHEN is satisfied
• But – The keyword is used to add negative conditions
• And – The keyword is used for adding more conditions to your steps
• Background – This keyword defines the steps common to all tests in the feature file.

Steps Definitions

Even if the feature file is ready with the test scenarios defined, we need to complete some more tasks.

It necessitates the need for an intermediate – Step Definition file. The mapping between each step of the scenario defined in the feature file is stored in the steps definition file along with the necessary function code.

Cucumber scans the step definition file to determine which function needs to be called when it executes a scenario step specified in the feature file.

Therefore, with each function, the code (i.e., GIVEN/THEN/WHEN) you want to execute with each test step, you can write it within the Step Definition file. Always ensure that the code/function has been defined for each step.
You can use both Java and Selenium commands to automate our test steps, as this function can be Java.

Test Runner

Runner class is used to run the tests. It uses the TestNG annotation @RunWith(), which tells TestNG what the test runner class is. TestRunner must be created under src/test/java within the runner folder.

Scenarios

A scenario describes the steps and expected results for a test case and is one of the core structures in the Gherkin language. We use the word “Scenario:” (or a localised one) at the start of each scenario. An optional scenario title follows it. There may be one or more scenarios for each feature. Every scenario also includes one or more steps.

To cleverly define the Cucumber test automation scenarios, there are a few tips and tricks.

• Define each step precisely to avoid confusing readers.
• Make sure that the test scenario does not repeat, use the scenario outline to implement repetition if required.
• Develop a test step for scenario outlines and multiple scenarios.
• Wherever possible, keep each step independent.  For example: “Given the user is logged in”. We can divide it into two steps

o Given the user enters the user name.

o Clicks on login.

Scenario outline

Replace the variables or keywords with the value from the table for the scenario. Every row in the table is a scenario.

Data Table

Data Table handles large amounts of data. They are very powerful. Nevertheless, you must deal with a list of maps or a map of lists.

Difference between Scenario Outline and Data Table

Scenario Outline

• Uses Example keyword to define test data for the Scenario
• Suitable for the whole test

Test Data

• There is no keyword to define the test data
• Applies only to the single step, below which it gets defined
• We need a separate code to understand the test data, and after that, it is possible to run it single or multiple times. However, it is for the single step, not the complete test.

Tags

Cucumber organizes your scenario execution with the help of tags in the feature file. We can define every scenario using a tag. In the runner file, we can confirm which specific tag (and so as the scenario(s)) Cucumber should execute. You can have any relevant text to define a tag and it starts with “@”.

You can define any tags within the feature file. It is possible to derive the tags and scenarios per your needs.

There are two key types of tags −
• Default tag – with their predefined meanings. Example @Dev,@Ignore
• Custom tag – It allows you to select appropriate text to define your tag.

We can define tag at a feature level as well. Consequently, it ensures that all the scenarios within that feature file inherit that tag. Based on the nature of the scenario, it is possible to use more than one tag for a single feature.

The special character skips Scenarios and Features. Further, it also works in conjunction with ‘OR’ or ‘AND’. Under such cases, when we skip a test, we can use the Special symbol “~” inside the tag.

Hooks

Cucumber Hook offers better management of the code workflow and thus helps us to minimize code redundancy. Often, it is an unseen step that helps us conduct our scenarios or tests.

Usually, we use two types of hooks- “Before” hook and “After” hook. The ‘before hook’ is executed before any other test scenarios, and the “after hook” is executed after all scenarios have been executed. Whether the scenario passes or fails, the method/function/piece of code defined within Before and After hooks always runs.

Tagged Hooks – Used for executing before and after hooks for a specific tag.

Example:
1. @Before (‘@RegressionTest)
2. @After (‘@RegressionTest)
3. @Before (‘@RegressionTest, @SmokeTest)
4. @ After (‘@RegressionTest, @SmokeTest)

Order or Priority of Cucumber Hooks
  • @Before (order = int): This runs incrementally, implying that value 0 will run first and 1 will be after 0.

• @After (order = int): This runs in decrement order, implying that apposite of @Before. Value 1 would be the first to run, and 0 would come after.

Cucumber Options

Reports

Pretty Format (HTML Report)

Pretty Format generates an HTML file containing the Cucumber test automation report. It is a readable report format where you can trace it easily.

JSON Report

Another reporting format arises to convey the report information to any other application. The test report in HTML format won’t help in such instances. Under such cases, JSON-Java script object notation is useful for generating Cucumber test reports.

JSON is an object that contains much information stored in text format. This reporting format serves as a payload of information which moves between servers and other applications can also use JSON reports.

Conclusion

Usually, BDD uses the Cucumber framework. It is an easy-to-understand open-source tool and includes new features. which can integrate Cucumber with any third-party tools/jars and Selenium.

Also, with its active help groups and members, it becomes easy for beginners in Cucumber or those with an intermediate knowledge in test automation to interact and address issues while using Cucumber/BDD.

Consequently, it serves as a bridge between the business and technical language.

Top of all, Cucumber supports integration with the Excel sheet and Jenkins.

---