_edited_edited.png)
1. Introduction
Recently I was working on a project where I had to pass a variety of input test data in the feature files & glue code using Cucumber tool. Deciding on to which format i.e. Examples Table or Data Table will be appropriate for my use case was getting bit challenging. I tried doing my research, but couldn't find any consolidated information as to which approach is a better choice and why? In this blog, I will walk through the Implementation of Examples Tables and Data Tables with some examples and highlight the Key differences between them.
2. Overview
Cucumber is a tool that supports Behavioral Driven Development (BDD) framework and allows to create specification based scenarios using Gherkin language. Some cases require combinations of test data as input to complete the execution of these scenarios. Writing the same scenario repeatedly with different sets of data/inputs can get cumbersome. Hence, Cucumber provides a special provision for parameterization in the form of Scenario Outline and Data Tables, thereby allowing user to pass the values from one step to another and validating the application behavior with different combination of data. Cucumber can be used to implement automated tests based on scenarios described in your Gherkin feature files. There are multiple ways to provide data to cucumber steps like Scenario Outline & Examples, Data Tables and External Files. In this blog we are going to see - Scenario Outline and Data Tables.
Let’s have a look at the usage and differences between each of them:
2.1 Scenario Outline - Examples Table and its Implementation
The Scenario Outline keyword can be used to run the same Scenario multiple times, with different combinations of data. The Parameterized variables are specified within angular brackets <> which acts as Headers in the examples table.
Test data for Scenario outline will be placed under the scenario using keyword “Examples”. A Scenario Outline must have one or more “Examples” associated with it.
Cucumber automatically runs the complete Scenario (i.e all Given/When/Then steps of that scenario) once for each row of data provided beneath Examples keyword. Here, the header is not counted as Data.
Cucumber will replace the parameterized variables <> in the Scenario Outline with actual data from the examples table during the execution.
Let’s see an example of Scenario Outline - Examples table in Feature File:
Given below is the Implementation of above Examples tables in Step Definition:
2.2 Data Table and it's Implementation
Data Table works only for the single step below which it is defined rather than the entire scenario
Data tables from Gherkin can be accessed by using the DataTable object as the last parameter in a step definition. This conversion can be done either by Cucumber or manually.
Test Data is directly specified below the particular step in a Scenario and no separate keyword is needed to define the test data. It doesn’t necessarily have a Header row either. Note: In the case where header row is provided in the data table, we would skip the first row while parsing the data in step definition.
Separate code is required (e.g. List, Map) to interpret the Data Tables in Step Definitions(or Glue code). Several methods are provided to convert tables to common data structures such as lists, maps etc. There are different ways to handle it, depending on the structure and complexity of the data. Most common are:(1) list of lists (2) list of maps and (3) table transformer
Data Tables can be accessed by using the DataTables object as a parameter in the Step Definition. For Example: In the case of the below two scenarios, ‘DataTable datatable’ will be passed as a parameter in the functions for ‘Given’ step and ‘When’ step respectively.
Depending on the input data , Data Table can be implemented using various Collections, for example
List<List<String>> tableName
Map<String, String> tableName
List<Map<String, String>> tableName
Let's see few examples of Data Table in Feature File and it's implementation in Glue Code
A. Example of DataTable without header in Feature File
Implementation of above data table using List<List<String>> approach:
B. Example of DataTable with header and single row in Feature File
Implementation of above data table using Map<String, String> approach:
C. Example of DataTable with header and multiple rows in Feature File
Implementation of above data table using List<Map<String, String> approach:
3. Key Differences at a glance:
Scenario Outline-Examples | Data Table |
Can be used to run the same Scenario multiple times, with different combinations of data | Works only for the single step below which it is defined, not entire scenario |
Separate Keyword 'Examples' is required to specify the test data | Test data can be specified directly below the required step (it may be with or without header row) without any keyword |
Cucumber interprets the input data automatically and no separate code is required to understand test data. | Separate code is required to interpret the input test data |
Works for the entire scenario | Works for single step in a scenario below which data is mentioned |
Usage: Mostly used when a scenario needs to be validated with multiple combinations of test data | Usage: Mostly used when we want to pass a list of input values into one single step (e.g. New user Registration form, adding muliple users data on the same page) instead of having a separate stepper separate value, go with Data Tables |
4. Conclusion
In this blog, we saw the different ways to pass input data through Cucumber. For repeated actions with different combinations of data, Scenario Outline-Examples is a better choice as it does not require seperate code to interpret the test data, Cucumber automatically interprets it. However, if we don't want to repeat the entire scenario but just one step, Data Table can be used. Certainly both approaches can be used to specify input test data thereby avoiding hard-coded values in the tests.
Utilizing these rich features of Cucumber enables Data Driven Testing and Parameterization, allowing engineers to create robust and reusable test scenarios, enhanced test coverage, reduce redundancy and make our test steps more readable and understandable.
Hope you find this information useful. Happy Learning!