Testing plays a critical role in helping developers improve the overall quality of software products. It helps you locate and fix defects before they make their way into production. Thorough software testing enhances code quality and encourages engineers to adhere to...
Sometimes it is necessary to access the value of a specific variable in more than only one module in a test case.
An example for this would be any kind of converter: In one module the value to be converted is read in. In another module this value is converted. Needless to say, in the converting module the value from the previous module should be used.
This blog post will show how to do this step-by-step.
- The Structure of the Ranorex Solution
- Step 1: Creating a Variable in Module 1
- Step 2: Creating a Variable in Module 2
- Step 3: Connecting Variables in different Modules to one Parameter
- Testing the Solution
The Structure of the Ranorex Solution
As you can see in the screenshot above, the solution “Converter” created for demonstration purposes consists of four different modules. Two variables (varTemperatureCelsius and varTemperatureFahrenheit) should be shared between the modules “GetValue” and “ConvertValue”. The temperatures are read from a weather-website in the “GetValue”-module.
In the “ConvertValue”-module the Celsius-temperature is converted from Celsius to Fahrenheit using another website and compared to the Fahrenheit-temperature from the first website. The whole example is available for download here.
Step 1: Creating a Variable in Module 1
At the beginning an “Open Browser”-action is recorded in the first module. Then a new “Get Value”-action in the second module “GetValue” is added.
Note: Before initializing a new variable, a repository item representing the UI element that displays the temperature needs to be created. This can be done by using the “Track”-button in the Ranorex Repository or by using the Ranorex Spy.
The value of the current temperature is stored in a variable. It is going to be created by clicking on the drop-down menu below the heading “Variable” and choosing the option “As new variable…”.
A context menu will be opened which should look like this:
Here the desired name of the variable and (optionally) a default value can be defined.
Note: The default value is used if modules are running separately and not from the test suite view. It will also be used if a variable is unbound and the test is started from the test suite.
Afterwards the repository item representing the value on the website and the attribute of the “Get Value”-action should access are chosen. The attribute holding the given temperature value is “InnerText”.
This step needs to be done for both Celsius and Fahrenheit values. In the upper right corner of the website the unit of the temperature can be changed.
At the end of the first step the “GetValue” module should look like this:
Note: The temperature value should not be used as identification criteria! The test will only work if the temperature is the same as when it had initially been identified. This can easily be changed by using the Path Editor in Ranorex Spy: Uncheck the “innertext” attribute and check a different appropriate attribute, e.g. “class”.
Step 2: Creating a Variable in Module 2
The step of creating a new variable needs to be repeated for every module the value from the first module should be used in. Here it is the module “ConvertValue” where a value is going to be converted from Celsius to Fahrenheit.
Firstly, the value from the previous module is used for the Celsius text field on the mentioned website. After that the result is validated in a user code action.
After recording and creating the needed variable, the module should look similar to this:
Note: For identification purposes, it would be easier if variables belonging together have the same name. However, this is only a recommendation and not a requirement.
Step 3: Connecting Variables in different Modules to one Parameter
In order to connect all needed variables to each other, a parameter needs to be created.
This is done by right-clicking the test case in the test suite view and clicking “Data Binding” in the context menu.
The test case properties pane will be opened:
Here it is necessary to add two rows in the “Parameters”- section of the window – one for each shared variable.
By clicking the drop down menu “Module Variable”, the variables associated with this parameter (“varTemperature(GetValue)” and “varTemperature(Convert Value)”) can be checked.
Finally, the test suite should look like this:
Testing the Solution
Now it is time to test the solution. This can be done by pressing “Run” in the test suite.
Note: If “Play” is clicked in one of the modules, the variables won’t be bound. In this case the default values of the variables are used.
The report file should look like this:
In this blog post you learned how to share variables from one module to another. There is one main concept which is always the same for every new module added to the test suite: Firstly a new variable in this specific module is created and then it is connected to a parameter of a test case.
Note: If a variable needs to be shared across test cases, it is almost the same procedure. The only difference is that a global parameter or a parameter in a parent test case is taken. A global parameter can be created in the test suite properties pane.
If something was unclear in this blog post, feel free to ask in the comment section or have a look at the following chapters in our user guide:
6 Strategies To Manage Your Agile Testing Life Cycle
Discover six strategies for managing your agile testing life cycle, including CI/CD, test automation, TDD, collaboration, flexible planning, and metrics
What Is Regression Testing? | Comprehensive Guide
Dive into the world of regression testing and explore techniques, best practices, and the role of test automation tools in the process.
Simplifying Your Testing Process With Codeless Automation
Codeless tools have seeped in through all the pores of digital product development; Wix and Squarespace have introduced significant changes to the way non-dev or even non-tech users can get involved in digital product development cycles.