Parameters

In this chapter, you’ll learn what parameters are, how to add them, and what you can use them for.

Parameters can be considered a data source with only one row, i.e. the simplest kind of data source. They are useful for keeping modules reusable and tests maintainable. They also allow you to pass variable values from one recording module to another.

Add a parameter

Parameters are added in the test suite view in an item’s Properties dialog. You can add parameters to:

• The test suite item ( = global parameters)
• Test containers ( = local parameters)

The parameters dialog

To access the dialog for adding parameters:

Right-click the item you want to add a parameter to and…

…for a test suite, click Global parameters….

…for a test container, click Data-binding….

The name of each existing parameter. Click on Add row… to enter the name of a new parameter.

The default value of each parameter. Assign a value to the new parameter. Any string is possible.

The current binding for each parameter. Use the drop-down menu to bind the new parameter to one or more variables.

Parameters in italics have been inherited from an ancestor. They can be edited only in the ancestor.

Click Auto-create to automatically create a parameter for any unbound variable. The new parameters will have the same name as the unbound variables. Then click Auto-bind to automatically bind the new parameters to the respective variables.

Use parameters

In this section, we’ll show you two examples of how to use parameters.

The first example is simple and useful for many kinds of tests. It is about using parameters to increase the reusability of a recording module.

The second example is more complex and more limited in its applications, but still highly useful. It is about using parameters to pass a value from one variable to another in a different recording module during test execution. This can increase efficiency and reduce test maintenance.

Example 1: Increase module reusability

For example, there are several tabs in the Ranorex Studio Demo Application, each offering a different functionality:

1. Open the AUT.
2. Click the tab for the screen you want to bring up.

This makes for a highly reusable module, and reusable modules increase efficiency. But there’s one problem: The name of the tab to click is different in each test case.

The easiest and most efficient way to solve this is with variables and parameters.

Define a variable

In the recording module StartAUT, we will make the repository item linked to the Click action variable.

Define a mouse-click action on a tab of the demo application and follow the instructions for repository variables in ⇢ Define variables. Name the variable $varTab.

Define parameter and link variable

Now we’ll define a parameter in the first test case (Introduction_testing) and bind the repository variable to it.

Right-click a test case and click Data-binding….

Under Parameters, name the parameter Tab and assign it the value Introduction.

And that’s it. When you run the test, it will go through the tabs automatically.

Example 2: Pass values across modules during test execution

In this example, we’ll show you how to take a value generated in one module during test execution and pass it to another module in the same test run. We’ll accomplish this with variables, parameters, and the Get value action.

To explain this, we’ll use a small database test in the Ranorex Studio Demo Application.

Download the sample solution

As this example is more complex, we’ve created sample solutions for you. Download the file below to follow along with the instructions. A finished sample is available at the end of this section.

Unzip to any folder on your computer.
Start Ranorex Studio and open the solution file.

Test description

In our example test, we’ll use data-driven testing to enter a number of persons into the database of the Ranorex Studio Demo Application. With each entry, a counter showing the number of entries will increase. At the end of the test run, we want to log the total number of entries to the report.

Initial test suite

The first six recording modules add the entries from a data source into the database, as explained in the previous subchapters.

The recording module GetDBCounter will extract the counter value and write it to a variable.

The recording module WriteMaxCounterToReport will log the counter value to the report.

Closes the AUT.

The counter value is generated dynamically during test execution depending on the amount of entries added. Depending on changes to the data source or the inclusion of conditions, for example, the final number will vary. Therefore, we can’t reliably know what the counter value will be during test execution, or it would require too much effort to find out each time. To log the correct value to the report automatically, we will need to make use of variables and parameters.

Extract value and write it to a new variable

First, we’ll use a Get value action to extract the counter value after all entries have been added during test execution and write it to a new variable:

Open the recording module GetDBCounter.

Add a Get value action that is linked to the repository item for the entry counter.

Create the new variable $varCounter. The value of the counter will be written to this variable.

Log counter value to report

Now, we’ll add the action to log the counter value to the report.

Open the recording module WriteMaxCounterToReport.

Add two new Log message actions as in the image below.

Add the new variable $varWriteCounter. This variable will receive the value from the GetDBCounter module and log it to the report.

Create a transfer parameter

During the test run, the variable in GetDBCounter will now receive the dynamically generated counter value. However, the variable in WriteMaxCounterToReport can’t retrieve the value yet, because variables and their values are local to their modules. We need to “link” the variables. We do this by binding them all to the same parameter.

The parameter that links the variables needs to be located in a common ancestor of both modules. In our case, the modules are in two separate test containers, so the first common ancestor is the test suite item RxSampleParameter. If the two modules were in the same test container, you could add the parameter there.

Right-click the test suite item RxSampleParameter and click Global parameters….

Under Parameters, add a parameter called parCounter.

Click OK.

Link variables to parameter

With the parameter added, we can now bind the variables to it and link them together. This way, the dynamically generated value will be passed from one module to another.

Right-click the test case AddPersonToDB and click Data binding….

Under Parameters, bind the inherited parameter in italics to the variable $varCounter.

Click OK.

Right-click the test case WriteReport and click Data binding….

Under Parameters, bind the inherited parameter in italics to the variable $varWriteCounter.

Click OK.

After you’ve run the test, you will see the counter value is logged to the report correctly:

Finished sample solution

Web test example

Extracting and passing on dynamically generated values is also relevant in web testing. The web test sample included in Ranorex Studio (Ranorex Studio start page > Sample solutions > Web example) demonstrates this:

This URL is needed in the ValidatePost module, so the test can navigate to the blog post and see if it was published correctly. It’s also needed in the DeletePost module to navigate to the correct post to be deleted.

However, as with the counter value in the Demo App, we don’t know what the URL will be during the test run.

Therefore, the module GetPostURL extracts the value, writes it to a variable, and passes it on to the other two modules. This works in the same way as explained in the previous example, except here, all modules are contained in the same test case. Therefore, the linking parameter is located in this test case and all variables are bound to it.