Modular test design is a way of promoting test case reusability and composition across a large test repository. To design modular tests, you can create a manual test where some of the steps call or include other test cases. This prevents testers from having to write the same steps over and over again in different high-level tests. Using a modular design approach, any test can become a building block of more extensive test scenarios. Still, they can also be executed individually if needed.

A called test can, in turn, also call other tests. You can compose a test scenario with up to five levels of depth.

Modular tests can also be parameterized. When calling a test, you can provide new parameter values according to the parent test data.

Upon executing, Xray will unfold all called test steps in the test run. This becomes transparent to testers as they only have to follow and execute the steps on the execution, even though test steps might come from different tests issues.

A common use case for modular tests is end-to-end testing. End-to-end tests often need to pass through the same area or component of the application before asserting the final result. With modular test design, you can reuse the tests for these common areas or components.


Modular tests limitations

  • Precondition issues will be ignored when tests are being called/included in other tests.
  • Modular test design only works with manual tests.
  • The call context dataset for called tests does not support multiple iterations.
  • There is a depth limit of 5 called tests: A → B → C → D → E
  • The total number of called tests allowed for a given Test Run is 200.

Designing modular tests

To start designing modular tests, you need to think about structure and reusability. Once you have identified the individual building blocks for a given test case, you need to consider if some blocks can originate separate test cases. If there are blocks that can be executed individually or later be reused for other test scenarios, consider creating different test issues and composing the initial test case with them.

To create a test case composed of other tests, you need to use call steps. Call steps can be interchanged with common test steps to define a test. Call steps are represented with the purple color in Xray.

Create a call test step

To define a call test step:

  1. Press the "Add Step " dropdown button and choose the "Call Test" option. A modal issue picker dialog appears.
  2. Select the manual test from your recent issues or search for tests by typing the key or summary and then select the test from the search results.
  3. Press "Add" once you have a test selected.

A new call test step will be created.

Parameterizing called tests

It is possible to specify and override the parameter values for called tests. After defining the call test step, you can edit the dataset in this context.

To define the test data for a called test:

  1. Hover the call test step and click on the dataset icon located in the actions toolbar (to the right of the step). The dataset dialog will appear.
  2. If there are already parameters defined on the called test, then you can add these parameters using the "Add Parameter" button.
  3. Edit the parameter values accordingly
  4. Save the dataset

Once parameters are defined on the call test step dataset, they will appear on the step body when the step is expanded.

Importing steps with call tests

Xray also supports importing steps with call test steps from the following sources:

  • JSON
  • Test
  • CSV
  • Clipboard

The import wizard dialog will prompt the user to map the call test and call test parameter columns when applicable.


Exporting steps to a CSV file

When exporting test steps to a CSV file, the call test steps, and their parameters will also be included on the CSV file as distinct columns. 

It is also possible to expand/unfold the call test steps when exporting test steps to CSV. To archive this, the option "Expand called test steps" must be checked when exporting to CSV.


When executing tests composed of modular tests, Xray will unfold/expand all steps and replace the parameters with their resolved values.

On the step number column (located in the left of the step), an icon indicates that a step belongs to another test issue in case users need to navigate to the test.

Parameter resolution

When resolving the parameter values, Xray will try to get the parameter from the closest context. If the parameter is not found, Xray will search the parent context.

For a given parameter P within a called test step, the value of P will be resolved from the first of the following contexts where P is explicitly defined:

  1. The call context dataset for the called test
  2. The call context dataset of the parent called test (current level >= 2)
  3. The resolved dataset for the Test Run (Test Run > Test Plan > Test)

  • No labels