top of page
hand-businesswoman-touching-hand-artificial-intelligence-meaning-technology-connection-go-

Cucumber with Data Driven Framework

Introduction

Data-Driven testing: What is it?

Data-driven testing, in its simplest form, entails the loading of data not directly related to the functional tests and then using that data to create new automated test cases. The customer order form seems to be a great illustration of this type of document. In this case, data-driven testing may be implemented by recording the single automated test and populating the various fields with values. After an automated test has been recorded, it will only contain the values you specified at the time of recording. There should be no problems with the application due to the data you entered, but there is always the possibility that something else could go wrong. You can modify your test for accepting variables and then enter such variables into data fields to ensure the application behaves as intended. Hence, data-driven testing enables you to execute this test every time you would like to create an order record, sending in such a new piece of data each time.

Data-driven testing with a scenario-outline is a simple task using Cucumber. By utilising cucumber's feature files, you can easily feed information into your test cases for data-driven testing. Take, as an example, the case where you wish to automate the process of logging into a specific programme. In this scenario, the feature file can be used to provide test data, such as a username and password, for the selenium code to evaluate. Feature files can be used to transmit a wide variety of information kinds. You can pass in a variety of different types of information, including strings, numbers, and even entire data tables. Data insertion can be used both within Cucumber and with external files, each of which has its own advantages and disadvantages.

Cucumber's Data-Driven Testing Framework

  • Examples of Parameterization without a Suggested Keyword

Cucumber Scenario Outline Data-Driven Testing

  • Examples of Parameterization with a Suggested Keyword

  • Table-Based Parameterization

Cucumber with External Files Data-Driven Testing

  • XML-based parameterization

  • Json-based parameterization

  • The Use of Excel Files for Parameterization

To perform data-driven testing with Cucumber, a series of test steps is executed multiple times using varying values fetched from the associated data source. Being a standard procedure for ensuring that tests continue to function properly regardless of the input values they are given, it is an important part of automated quality assurance.

Below are some of the most common external data feeds or data sources used in data-driven testing:


Data Driven Framework



MS Access Tables (.mdb)

XML Files (.xml)

CSV Files (.csv)

MS Excel Sheets (.xls, .xlsx)

A data feed and data source not only stores the input values for Selenium automated testing, but it may also be used to store both expected test result as well as the actual test result. This can be used to compare the outcomes of different test runs and to archive the results for later use. A Cucumber test consists of two parts, or "Steps" and "features," that must be completed.

Steps: Procedures are mathematically defined as functions. Use these methods to facilitate a testing procedure. The action might be anything from loading a web app to clicking an element to typing text into an input box. These procedures are created in your preferred programming language and contain the necessary text to activate them.

Features: You have written a series of scenarios that make up the features. They begin with keywords to describe the activity, and Cucumber then maps the keywords to the appropriate phase.

Using the illustration could help clarify the situation.

Scenario: clicking the icon brings up the menu.

Given you have loaded the homepage,

When you select this item from the menu,

Then a selection bar will appear.

There are four lines in the above example.

First Line:

That we have reached the beginning of the scenario under test is all that this scenario line does. Essentially, a synopsis of the events unfolding in this evaluation.

Second Line:

Based on the context of this step's use, we may infer that the step's code will launch the application's home page in a web browser.

Third line:

This action will choose the menu item once the page has loaded. For this reason, the code would contain a selector for page's menu icon and react to a click on that alone.

Fourth line:

The presence of a menu is checked for in the final line. As it is, what has been described above is clear and easy to comprehend. The step specification would, however, once again include a selector for the relevant menu element. The programmed would then attempt to retrieve the specified element to check its availability and accessibility.

Why We Need Data-Driven Testing ?

  • Data-driven testing reduces the time spent on test upkeep because instead of maintaining multiple test cases, you just need to maintain a single test case that checks all possible combinations of data values.

  • By updating the test data, new or removed scenarios can be tested without having to rewrite the test case.

  • Reusability is improved, and it's also simple to keep up with.

  • Another benefit of data-driven testing is a decreased potential for redundant or duplicate test cases including automation testing scripts.

  • Only one test case is necessary to cover all possible outcomes, good and negative.

  • Also, it helps with speedier execution and increases test coverage.

Selenium WebDriver's Data-Driven Framework

  • One of the most well-liked tools for realizing iterative testing and development is Selenium's Data-Driven Testing Framework.

  • Data Driven Framework is used for this purpose; it is a framework for data-driven testing that may be used to power test cases and test suites with information obtained from external sources.

  • A data feed or other external source is linked to by the test script so that the necessary data manipulations can be performed.

  • By decoupling the data used in tests from the actual implementation of those tests, the Data-Driven Framework makes it easier to keep the test code up-to-date.

  • Modifying the test data set is necessary for even the smallest adjustments to the business rules, with or without modifying the test code at all.

  • To ensure that your online app works properly across all browsers, you can use Selenium WebDriver to do automated cross-browser testing.

  • The inability to conduct CRUD operations (create, read, update, delete) on external data streams (such as CSV files, Excel sheets, and more) is a major shortcoming.

  • It utilizes application programming interfaces (APIs) from other companies, such as Apache POI, so that you can retrieve data from and execute necessary manipulations on data stored elsewhere.

Apache POI: What is it?

The Apache Software Foundation creates and disseminates free, open-source software; one such library is the Apache POI (Poor Obfuscation Implementation). As the most popular API for implementing data-driven tests in Selenium, it is widely utilised. Apache POI's library files provide an application programming interface (API) for working with Microsoft Word, PowerPoint, Excel, and other Office document formats. Apache POI seems to be the Java equivalent of Excel, allowing you to import and export data from and to other data sources while retaining full editing capabilities.

Cucumber with Data-Driven

Achieving the data-driven testing with cucumber is as simple as importing cucumber feature files and passing them to your test cases. Let's continue with the same scenario, where you're trying to automate the login process for a certain application, and look at how it might work. In this example, the feature file can be used to supply the selenium code with test data consisting of a username and password.

The insertion of data can be done in a number of ways, both natively within Cucumber and via referencing external files.

  • Two different methods of DDT with cucumber are detailed below.

  1. Using Scenario Outline and Example

  2. Parameterization without Example Keyword

Data-driven testing with Selenium cucumber: a practical guide

The importance of data-driven testing has been highlighted. To do this, we shall study the cucumber language. As was previously noted, the feature file is a great alternative to passing information via hardcoding in Cucumber. Let's break down the steps necessary to reach this goal.


Cucumber Data-Driven Testing using Example and Scenario Outline

Scenario Outline - An outline of a scenario can be used to replicate an experiment with many data variations. E.g. It is possible to data-drive our scenario twice, allowing for simultaneous user logins.


Examples - All case study descriptions must be followed by a detailed set of examples. Information that must be conveyed to the scenario is stored here.



The 'Login' feature file can be found down below.

It is clear from the preceding illustration that the 'Examples' keyword and the 'Scenario Outline' work hand in hand when it comes to passing several pieces of data in a test script. Regular 'Scenario' cannot be used with the 'Examples' keyword.

The column headings in the Scenario Outline are "username" and "password," which are the identical values used in the "Examples" section. In this case, Examples will serve as a "|-separated" test data table. As we put our application to the test, we can use a variety of data. Since there are now two rows in the "Examples" table, we will run the entire scenario twice.

For the step definition's Test Steps to comprehend the feature file's parameterization, we need to employ the 'Regular Expression'.


The following statements will let Cucumber realise that the connected Test Step requires some input.



Parameterization without Example Keyword

Instead of manually entering values in Test Step, we can simply transfer information about the scenario from a feature file.


Login Feature Keyword File without parameterization




Due to the fact that we are only supplying the single set of data, we have omitted the Scenario outline with Examples Keyword from the preceding example.

The user then inputs in "xyz1234 and kk12kk12."

We had passed Username and Password from Feature File into the preceding statement, and they will be included into the Step Definition without any further action on our part. Furthermore in this case, 'Regular Expressions' are required in Step Definition.


Definition of the steps associated with the given feature file



@Given (“user is on home page”)

public void user_is_on_home_page () {

}

@When (“user clicks on sign In link”)_

public void user_clicks_on_sign_In_link () {

}

@Then (“user should be landed on login page”)

public void user_sould_be_landed_on_login_page () {

}

@And (“^user enters(.*) and (.*) $”)

public void user_enters_username_and_Password (String username, String Password) {

login.userNameTxt (username);

login.passwordTxt (Password);

}

@And (“Click on login”)

public void click_on_login () {

login.loginBtn ();

}

@Then (“User should be logged in”)

public void User_should_be_loggedin () {

}

}


The feature file will be queried for a login and password in the form of strings, and the test scenario will be run only once using those credentials.

Advantages of Cucumber Use:

  • As a result of its readability, it may be understood by businesspeople.

  • Any language can be used to document the steps.

  • Because to its textual nature, it can be used to define specifications for end users.

Disadvantages of Cucumber Use:

  • Participation from users is necessary for accurate scenario descriptions.

  • Keeping track of procedures and potential outcomes simultaneously is necessary.

Conclusion:

The term "data driven testing" refers to testing that is, well, driven by data. It makes scenarios easier to read and aids in keeping test scripts up to date. By combining both positive and negative situations, we may get a high level of test coverage, which in turn leads to improved application quality and stability. Instead of permanently embedding the test data into the script's logic, we're taking advantage of dynamic data to keep the script's file size to a minimum. For a massive pool of test data, you can utilise the same test script. Several iterations of the same Scenario can be conducted, with varying parameters each time. Common applications include running the same set of test scripts on a large amount of data for testing purposes or performing regression testing. Since data has become increasingly important in the modern world, there has been a rise in the need for automated data-driven testing, which has led to the development of a number of useful automation-testing tools and frameworks.




201 views0 comments

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page