Parameters

Parameter options for test cases in Test Manager, including a 250-parameter limit, naming uniqueness rules, and string type constraints.

Creating parameters

You can create parameters for each test case within a test set. You can add a maximum number of 250 parameters, each required to have a unique name in the context of a test case.

Parameters can only be of type String.

1. Open the test case to which you want to add parameters.
2. Go to the Parameters tab.
3. Select Create Parameter and fill in the fields below:
   1. Name - Give the parameter a unique name.

When you name the parameter, you can use letters, numbers, spaces, and the following characters: -, _, ,, and ..

For example, name the parameter as adminName. 2. Default value - Type the default value of the parameter.

Remember that parameters can only be of type String.

This Default value field is not mandatory, so if you leave it empty, then the parameter will be an empty string.

For example, set the default value to JohnDoe. 3. Hint - Offer additional information about the information that the parameter holds.

For this example, add the following hint: The supervisor of the organization.

4. Select Create to create the parameter.

Parameters that you create in the Parameters tab of a test case can currently be used only for manual test executions.

Editing parameters

After you create parameters, you can edit them, according to your use case.

1. Open the test case for which you want to edit a parameter.
2. Go to the Parameters tab.
3. Select Edit next to the parameter that you want to edit.
4. In the Edit Parameter window, update the fields that you want to change.
5. Select Save to save the changes.

Using parameters in manual testing

You can use parameters in manual or automated testing with the default values that you set for each test case. Or you can override the default parameter values for the test cases within a test set. For information on overriding parameter values, visit Overriding parameters.

Manual test cases support only a single default value per parameter. There is no built-in way to define multiple value sets (an iteration or parameter table) for one manual test case. To run a manual test case against different parameter values, create separate test sets, each overriding the parameter to a different value for that test case.

1. Create a new test case.
2. Depending on the execution type you want to use, follow these steps:
   • Manual execution:
     1. Go to the Manual Steps tab and add manual steps.
     2. To reference parameters into the manual steps, input their name between double curly brackets.

For example, to add the username parameter inside a manual step, reference it as {{username}}.

• Automated execution: During the automated execution of a test set, the Studio arguments from the automation (corresponding to each test case) are automatically applied (as parameters) in Test Manager, at test-set level for each test case added in the test set.

For automated executions, Studio arguments are surfaced in the Override parameters view at the test-set level. They do not appear in the Parameters tab of an individual test case, which is reserved for parameters that you manually create in Test Manager.

Test Manager parameters are always of type String. Because of this, data is passed from Test Manager to a Studio argument only when that argument is also of type String. If the Studio argument uses a different data type, the value is not passed, even if the names match.

Note:

Test Manager parameters do not automatically map to Studio arguments, even when the names match, and there is no global variable shared across test cases in a test set. Arguments, defined in Studio and overridable at the test-case or test-set level, are the supported mechanism for passing values between test cases. Test Manager does not aggregate test-case data at the test-set level natively; for test-set-level reporting, use an external reporting tool.

Best practices for test case arguments and data

Managing larger or variable datasets

If input values are extensive or need to vary across test runs, use data-driven testing instead of manually maintained parameters. Test Manager supports data-driven testing using Excel files. UiPath Data Service or Test Data Queues (managed through Orchestrator) can also be used for structured data and dependencies.

Data Fabric/Data Service linked test data

When a Data Fabric/Data Service entity is linked as test data, each row becomes its own test variation. Test Manager does not support grouping multiple rows into a single logical variation. If one variation needs several related records (for example, a transaction with multiple line items), use a parent record as the variation driver, then use activities in the workflow to query the related child records from Data Fabric at runtime (for example, by a shared ID).

Interdependent test cases

For test cases where one test case's output feeds another's input, use an external data store rather than relying on in-memory dependencies between test cases, for example:

• Orchestrator Assets
• Data Service
• Test Data Queues
• An external database or file

If reuse in memory is critical, combine the relevant logic into a single workflow or test case instead.

Result

The parameter is created and available in the Parameters tab of the test case. For manual executions, you can reference the parameter in manual steps using double curly brackets, and the value is applied at runtime.