Basic Structure of Cucumber Framework

Introduction:

Cucumber is a popular open-source tool for Behavior-driven development (BDD). It is widely used in software development to bridge the gap between technical and non-technical team members, making it easier to define, document, and automate the testing of software features in a human-readable format. Cucumber encourages collaboration and communication between developers, testers, and business stakeholders by providing a common language for specifying and testing software behavior.

Language:

Cucumber itself is not a programming language but it’s a framework that supports multiple programming languages. The core of Cucumber relies on a plain-text, structured language called Gherkin, which is used to write test scenarios in a human-readable format. Gherkin is not a programming language. It is used to write feature files.

Feature file:

Feature files follow a specific structure using Gherkin syntax that includes keywords such as Feature, Scenario, Given, When, and Then. These keywords are used to describe the behavior of the software.

Feature files contain one or more scenarios.

For testing purposes, feature files are placed in the src/test/resources/features directory with ‘.feature’ extension. This is in accordance with the standard Maven project structure for Java-based projects and ensures that feature files are kept separate from production code.

Feature: Describes the high-level functionality.

Scenario: Describes specific test case.

Given: It describes initial state of test case (Precondition)

When: It describes action to be taken (Action)

Then: It describes expected outcome (Result)

Data-Driven Testing in Cucumber using Scenario Outline:

This is used to run the same scenario for 2 or more different sets of test data.

The structure of a Scenario Outline includes:

Examples Keyword: The Examples keyword is followed by a table that provides sets of input data and expected outcomes. Each row in the table represents a different set of values for the scenario. This contains the data that must be passed on to the scenario.

Placeholder Values: Within the Scenario Outline steps, you can use placeholder values enclosed in angle brackets, eg: <username> <password>. These placeholders are used to represent the dynamic parts of the scenario that will be replaced with data from the Examples table.

Data-Driven Testing in Cucumber using External Files

• Parameterization using Excel Files

• Parameterization using Json

• Parameterization using XML

Here is the screenshot of Data driven testing using Excel file:

In the above example sheetName is the name of the excel sheet i.e. ‘registration’ and row number is given in the example table.

Here is screenshot of 'registration.xlsx' file:

Step definition file:

Step definitions are written in a programming language (e.g., Java, Ruby, Python) and map the Gherkin language in feature files to actual code. Step definitions define the actions that need to be taken for each step in a scenario, making the scenarios executable.

The step definition files are typically created in a separate package or directory specifically dedicated to storing step definitions. The location of step definition files may vary depending on the project structure and the programming language you are using, but some common conventions exist.

In Java-based projects, step definition files are often placed in the src/test/java directory, which is a standard location for test-related code. Within this directory, you can create packages to organize your step definition files. In that package create .java class file.

Test Execution File:

The test execution file is responsible for running the tests. It is a trigger for the execution of feature files. It parses the feature files, matches the steps in the scenarios with the corresponding step definitions, and executes the tests. It generates reports and logs to provide information on test execution.

Here’s the test execution files are under ‘Pages’package.

Logging:

Logging is the process of writing log messages during the execution of a program to a central place. If we use system.out.println , it shows only in console ,we will lose all logs when we close console. To overcome this, we can create Logger class, in which, there are some methods like info, warn, error, fatal, debug or you can add logging statements within your step definition methods to capture and record information during test execution. The level of detail in the logs depends on your requirements, but it's common to log actions, test data, and important checkpoints within your tests.

Reporting and Documentation:

· The test results are reported in a human-readable format, making it easy to understand which parts of the software behavior passed or failed.

· Cucumber generates detailed reports and documentation, showing the status of tests and providing visibility into test coverage.

· These reports help in identifying and resolving issues in the software.

· Reporting is crucial for summarizing and presenting the results of your BDD tests.

· Cucumber provides built-in support for generating reports, but you can also use third-party libraries and tools for enhanced reporting.

· After running your Cucumber tests, it generates HTML, JSON, and other report formats.

· Some teams prefer third-party reporting tools like Allure, Extent Reports for more advanced and customizable reports.

· To generate and view reports, you need to run your Cucumber tests and configure them to produce the desired report format.

Keep learning!!

Thank you.