In this chapter, 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 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.
Screencast: The screencast Parameters walks you through the information found in this chapter.
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)
Note: When you add a parameter to an item, all its descendants inherit it.
For the test suite item, all test containers inherit it.
For test containers, this means that descendant test containers inherit it, but not siblings or parents
The parameters dialog
To access the dialog for adding parameters:
- Right-click the item you want to add a parameter to and…
a. …for a test suite, click Global parameters….
b. …for a test container, click Data-binding….
-
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 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, find 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
Note: This example is quite short and so does not come with a dedicated sample solution.
Consider a typical AUT that offers different functions. It presents these functions on different screens that users access through the UI.
For example, there are several tabs in the Ranorex Studio Demo Application, each offering a different functionality:
To test these screens, you need to create several different test cases, one for each screen.
Why? Because you’re testing a different functionality on each screen, the test steps will be different in each case. However, one of the first steps always stays the same: Opening the AUT and bringing up the screen. It always consists of these actions:
- Open the AUT.
- 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, let's 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 would be [@accessiblename=’Introduction‘]. For the Test database tab, it would be [@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.
And that’s it. When you run the test, it goes through the tabs automatically.
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 our example test, we’ll use data-driven testing to enter several 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
-
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 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, you cannot 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 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 will be 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 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.
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 will be replaced for the test run.
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.
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, 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.