Overview

Let’s say we have five Cucumber tests that validate the same flow but with different data permutations. Furthermore, since several users created these tests manually, we can see slight discrepancies in the step wording.

Why is this problematic? Having 5 test issues means 5x maintenance whenever the specification needs to change. Further, manual multi-user creation or adjustment leads to messier step definitions for automation engineers (as we can have slightly different steps, with different wording, that perform exactly the same actions).

In this tutorial, we will optimize the efficiency of this mini regression suite via data-driven automation with the help of BDD Steps Library and Parameterized Tests features of Xray.

BDD Steps Library

First, we will consolidate the steps and improve future reusability. Xray indexes Gherkin steps automatically in the library whenever users create/edit Cucumber-type Tests/Preconditions. We will open the project library from the Testing Board.

Now, we will choose any redundant steps and edit it to have the desired syntax version. We will parameterize the dynamic parts with descriptive variable names. We will also surround those parameters in quotes as an optional good practice.

Once the library is updated for all step variations, we can go to one of the Cucumber tests for which we’ve done the edits (using the link under the definition).

We adjust its whole Scenario definition using the auto-complete functionality (for the steps that have not been updated automatically from the library). Remember to prompt the suggestions using the shortcut specified in the tooltip.

The final form of our data-driven Scenario looks like this:

Once the step optimization is completed in this updated “master” test issue, we can delete or archive the other four Cucumber tests and remove the outdated iterations of steps from the library (keep in mind, steps not marked as “static” are automatically deleted when they are no longer being used by any issue).

If tests require the same actions, you can select the option from the suggested list instead of typing. For new actions, consider creating them in the BDD Steps Library first, rather than in the test issues - that way you can avoid redundancy and improve consistency upfront.

Next, we will complete the upgrade to data-driven automation using parameterized Cucumber tests.

Parameterized Cucumber Tests

With the variables syntax (<>) already in place, we only need the dataset to provide the permutations for the execution. We can add it from the same screen by specifying the data manually or importing it from CSV.

In this case, we just recreated the same permutations that were present in the five original tests. Just keep in mind that one of the benefits of this data-driven approach is that you can easily scale the dataset up or down without worrying about adjusting multiple test issues one by one.

When we get to the execution, here is what you see in the Test Run details - several iterations of the same Scenario, with the data values replacing parameter syntax and the execution status per data permutation.

Data-driven precondition

As an optional exercise, let’s say we notice that many different tests will use the Given step as the precondition. We then decide to separate it out.

Here is the tricky part - the dataset, including parameters from both the test and the precondition, is always in the test issue. Whenever you have a data-driven precondition, you must ensure the dataset for each associated test has the parameters and values specified in that precondition.

So, in our example, we can execute the updated test issue without any changes to the dataset to see this breakdown in the Test Run details. Notice that the value replacement highlighted in blue is exactly the same as before we had a precondition.

Tips

• If the BDD Steps Library feature is out of sync for any reason, you can launch Reindex from the project settings to make sure all the steps you need are in the library.
  
  You can track the status from the same triple-dot menu.
  
  
• Ensure the parameter name syntax is the same between the script and the dataset.
• Consider adding the project-level lists in Xray settings for parameter values that you frequently reuse.
• If necessary, you can override the test-level dataset with the one in the test plan or the test execution.
• You can achieve the same results using the Scenario Outline format with the Examples table in the definition (like having embedded data) and no dataset defined at the Test level; Xray supports this implicit data in case you want to embed it directly in the Gherkin specification. It depends on the dataset size and if you wish to mix it with the script for review clarity purposes.
  

References

• BDD Steps Library
• Parameterized Tests