In this article, you’ll learn what parameters are, how to add them, and what you can use them for. Parameters help keep modules reusable and tests maintainable, and they let you pass values between recording modules during test execution.
Screencast: The screencast Parameters walks you through the information found in this article.
What are parameters?
Think of parameters as named values that you define on the test suite item or on a test container, and then bind to variables as needed. This makes it easy to:
- Reuse the same module with different inputs, and
- Share values across modules during a run.
Note: The page compares parameters to a “data source with one row.” Use this as a mental model, but remember that parameters primarily behave as scoped named values that you bind to variables.
Add a parameter
Parameters are added in the test suite view in an item’s Properties dialog. You can add parameters to:
- Test suite item → global parameters
- Test containers → local parameters
Inheritance rules
When you add a parameter to an item, all its descendants inherit it:
- Parameters added to the test suite item are inherited by all test containers.
- Parameters added to a test container are inherited by its descendants, but not by siblings or parents
Open the Parameters dialog
To open the dialog for adding parameters:
Right-click the item you want to add a parameter to and select one of the following:
- For the test suite item, click Global parameters…
- For a test container, click Data binding…
Parameters dialog overview
- The number of parameters you added. There is no limit.
- The name of each existing parameter. Click 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 have the same name as the unbound variables. Then, click Auto-bind to automatically bind the new parameters to the respective variables.
Use parameters
This section provides two examples: a common reuse pattern and a “value transfer” pattern for dynamically generated values.
Example 1: Increase module reusability
Many AUTs include navigation where the steps are identical except for which screen/tab you open. In the Demo Application, you might have multiple tabs (e.g., Introduction, Test database, Image-based automation), but the basic “open AUT → click tab” pattern stays the same.
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, 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, 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.
Note: The parameter value is the attribute value in the RanoreXPath that identifies the UI element. For the Introduction tab, this is [@accessiblename=’Introduction‘]. For the Test database tab, it is [@accessiblename=’Test database‘]. For more information, review RanoreXPath
- Bind it to the variable varTab and click OK.
- Repeat this for the other test cases and replace the parameter value with the attribute value that identifies the respective tab, for example, Test database, Image-based automation, etc.
Result: The same StartAUT module can be reused across multiple test cases; the parameter controls which tab is clicked.
Example 2: Pass values across modules during test execution
This example shows 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.
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.
Topic: Parameters – passing values across modules
Time: 15 minutes
Install the sample solution:
- Unzip to any folder on your computer.
- Start Ranorex Studio and open the solution file.
Test description
In this example test, data-driven testing is used to enter several persons into the database of the Ranorex Studio Demo Application. With each entry, a counter showing the number of entries increases. At the end of the test run, the application logs the total number of entries to the report.
Initial test suite
- Starts the Demo App and clicks the Database register.
- 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 extracts the counter value and writes it to a variable.
- The recording module WriteMaxCounterToReport logs the counter value to the report.
- Closes the AUT.
The counter value is generated dynamically during test execution, depending on the number of entries added. Depending on changes to the data source or the inclusion of conditions, for example, the final number varies. Therefore, you cannot reliably know what the counter value is during test execution, or it requires too much effort to find out each time. To log the correct value to the report automatically, you need to make use of variables and parameters.
Extract the 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 is written to this variable.
Log counter value to report
Now, 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 receives the value from the GetDBCounter module and log it to the report.
Create a transfer parameter
During the test run, the variable in GetDBCounter now receives 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. You need to “link” the variables. You 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.
Note: Leave the value empty to show that this is a parameter that receives its value during test execution. You can enter anything; the value is replaced for the test run.
Link variables to a parameter
With the parameter added, you can now bind the variables to it and link them together. This way, the dynamically generated value is 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.
Repeat the process for the second variable in the other test case:
- Right-click the test case WriteReport and click Data binding….
- Under Parameters, bind the inherited parameter in italics to the variable $varWriteCounter.
- Click OK.
In this way, you can pass values from one module to another or others in any test container, so long as all modules have access to the same parameters. Naturally, this also only works chronologically, i.e. the giving module needs to be executed before the receiving module.
After you run the test, you can see the counter value is logged to the report correctly:
Topic: Parameters – passing values across modules
Time: 15 minutes
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:
The module PublishNewPost enters a post title and content and then clicks the Publish button in WordPress. When you publish a post in WordPress, it automatically generates a unique URL for the published post.
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, you don’t know what the URL is 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.