Run Properties – ACCELQ

Introduction

In ACCELQ, Run Properties are a powerful feature that allows for dynamic data handling and sharing data across test cases within a Test Job. This guide will explain what Run Properties are, how they work, and best practices for their use.

Related Concepts in ACCELQ

Before diving into Run Properties, it's important to understand some key concepts in ACCELQ:

Action: A modular and reusable block of logic that takes input parameters and can output one or more values. An Action forms a "Step" in a Scenario.
Scenario: An assembly of multiple Actions, representing a business process being tested. All the parameters of the constituent Actions become parameters for the Scenario.
Test Case: A specific instance of a Scenario with defined input data for all the parameters of the Scenario's steps.
Test Suite: A collection of Scenarios grouped for the purpose of execution and tracking.
Test Job: An execution instance in ACCELQ. You could either execute a Scenario or a Test Suite.

The Need for Run Properties

Run Properties are essential when you need to:

Input Requirements: Provide data values for some of the Scenario parameters in the test job, that aren't known in advance.
Output Requirements: Share data between Test Cases within a Test Job.

Real-World Example

Consider a requirement where the IP address of a back-end service changes every time the service is deployed. Assume the application URL is made up of this dynamic IP address, and the URL is a parameter for a step in a Scenario.

Since this information is dynamic and changes with every deployment, you cannot input this value in the Test Case of the Scenario. Users need to pass this information at the time the test is executed. By setting up this parameter pointing to a Run Property, you make it possible to input this dynamic information at runtime.

What are Run Properties?

Run Properties are dynamic variables that can be used to:

Accept user input during test execution by overriding Action Input Parameters in Scenarios.
Store and share output data between Test Cases within a Test Job, by redirecting the output parameters of an Action to a Run Property.

These use cases are discussed in detail in the following sections.

Creating and Managing Run Properties

Run Properties are created and managed in the Resources section of the project.

Here, you can create, edit, or delete Run Properties.
Careful management is crucial to avoid confusion.

Using Run Properties for Input Parameters

In a Scenario, select the Action parameter whose value is required to be supplied during execution time.

Choose the option to derive the input from a Run Property as shown below.
Select an existing Run Property, or create a new one from here.
During Test Job execution, the system will consolidate all the Run Properties requirements across all Scenarios and steps, and prompt for inputting the values.

When executing the ACCELQ test job from CI tools such as Jenkins, Bamboo, etc, you can supply this information through the CI plugin.

Note: ACCELQ does not permit using Run Properties directly in the Action logic. This ensures that Action logic is not tightly coupled with runtime decisions.

Using Run Properties for Output Parameters

Another equally important use case for Run Properties is the sharing of output data from one of the test cases to subsequent test cases in the test job.

Imagine a requirement where a step in a Scenario generates an output (such as the Order ID of the newly created order), and you need this Order ID in the next Scenario to modify the order. You could store the output from the first Scenario step in a Run Property and use the same Run Property as input in the second Scenario step.

Select the Action's output parameter whose value is required to be stored in a Run Property.

Redirect the output to a Run Property.
Select an existing Run Property, or create a new one from here.
This Run Property can now be used to supply data for a subsequent Scenario step parameter.

Note: When using Run Properties for data sharing, carefully plan the order and distribution of Test Cases within your Test Job to ensure proper data flow.

Important Considerations

Data Lists in Action Parameters

When the Run Property is linked to an Action parameter that accepts a Data List, the system will present a dropdown with only these options for the Run Property when the test is executed.

In the case where the same Run Property is used across multiple Action Parameters in the test job and the Data Lists accepted by these Action parameters are not consistent, the result is incorrect. The system presents a simple input field to enter a value for this Run Property.

Note: If the Action input to which a Run Property is linked, is an encrypted input, then the Run Property will be presented as a masked input during test execution.

Data Driving Limitation

When an Action input parameter is linked to a Run Property, all Test Cases in that Scenario will use the same value for the parameter. You cannot data-drive with Run Properties.

Parallel Execution

In parallel execution (on a single Agent), where a Test Case in a Scenario outputs to a Run Property and another Scenario takes this Run Property as input, correct sharing will only work if the order of Test Case execution allows for it. If the test case outputting the Run Property is not executed ahead of the test case that uses it as input, then the result will be invalid.

Distributed Execution

In distributed executions where a test job is split across multiple Agents, Run Property sharing is only possible for Test Cases running on the same Agent. In a distributed run, the system automatically divides the total test cases in a job across the available Agents. Run Property values that are populated as outputs from Action outputs are not shared across test cases running on different Agents.

Conclusion

Run Properties in ACCELQ provide a flexible way to handle dynamic data, override Action Parameters, and share information between Test Cases within a Test Job. By understanding their capabilities and limitations, especially in the context of different execution models, you can effectively leverage this feature to create more robust and adaptable test scenarios.