top of page

Data Driven Testing

Data Driven Testing:

In Cucumber, "data-driven" testing refers to a methodology where you separate the test logic from the test data. This allows you to execute the same test scenario with multiple sets of input data. This approach is particularly useful when you want to test the same functionality with various input values to ensure that the application behaves correctly under different conditions.

When you separate the test data from your Cucumber feature files and place it in a separate file or location, this is often called as "external test data" or "external test data files." The most common ways to manage external test data in Cucumber are by using DataTable or data Examples within the feature file, or by using external data sources such as Excel.

The benefit of separating test data from test logic is that it makes your scenarios more readable, maintainable, and flexible.

In this blog i have covered getting data from sources like

  • Getting data from Scenario Outline with Examples(Feature file)

  • Getting data from Property file

  • Getting data from Excel

  • Getting data from DataTable(Feature file)

Lets start our project by adding dependencies in pom.xml

Before adding dependencies lets see what is actually a dependency means

Dependency: It is a software , library or module that allows to reuse existing code and avoid reinventing the code.

  • Go to Maven Repository (

  • In Search box type--> selenium java

  • click on Selenium Java which contains link org.seleniumhq.selenium » selenium-java

  • click on latest version could be in this pattern 4.14.1

  • click on the box where contain the dependency box

  • It says copied to clip board

  • Just paste the dependency in your pom.xml file

  • Add all required dependencies in our project

  • Thing to keep in mind

--> While adding dependencies to poi-ooxml-schemas, poi, poi-ooxml instead of adding latest versions for every dependency. Add the common version of all three.

Now lets create the Feature file.

-->Feature file contains the components like Feature, Scenario

Feature: tells high level description of the functionality being tested


  • Describes specific test case.

  • Each Feature file contains one or more scenarios.

  • Scenarios are written in Given -When-Then format

  • Given: Describes pre-condition

  • When: Describes an action

  • Then: kind of validating or checking whether the expected and actual result are same or not

Step Definitions: To automate the steps/tests described in the feature file we use Step Definitions.

  • We can also say that Step Definitions used to map the Gherkin Steps to actual code.

Right click On Feature file -->Run as-->Cucumber Feature it automatically generates Step Definitions in console

Copy the Step Definitions from Console then paste in

Property Files:

  • We usually store the data in the form of Key-Value pairs.

  • We also store the data in some other forms.

  • These files manage the configuration of our cucumber tests(browser=chrome)

  • Its easier to switch between test environment like chrome, edge, firefox etc.

  • its easier to change the test data without touching the code in step definitions or any other classes.

  • In detail it works same as like getting data from Excel file.

  • To read the data from configuration file we need to write code in our framework.


  • It plays a very important role in Cucumber BDD test automation framework.

  • We need to write the code in framework to read data from excel and write data to excel file.

  • Apache POI(dependency) library is used to read data from excel.

  • This is very helpful when we want to run single scenario with multiple sets of data.

Page Objects/Page Factory:

  • It is like a design pattern. Nothing but storing all the pages information in a single package.

  • Each page contains corresponding elements along with the actions they performed.

  • We don't add all the elements present in that page. we add only what we required for our tests.

  • Now Create and add elements required for our test scenarios written in Gherkin.

Folder Structure:

  • This is the Folder Structure of any MAVEN project looks like.

  • As an Automation Tester we usually don't touch the src/main/java and src/main/resources directories.

  • Its not mandatory not to touch the main directory.

  • As an SDET we work on src/test/java and src/test/resources.

  • src/test/java= we write .java classes.

  • src/test/resources= we usually add .properties, .xlsx , .feature files.

This is my git address where i pushed the code related to this post, just in case if a miss any details regarding this project.

Hope it will help someone.

Thank You,


229 views0 comments

Recent Posts

See All


Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page