Ranorex Logo

Sharing Data from One Ranorex Module to Another

|
Sharing Data from One Ranorex Module to Another||||||||||

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
  • Conclusion

The Structure of the Ranorex Solution

Structure

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.

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…”.

02-Store-Value-to-Variable

A context menu will be opened which should look like this:

AddVariable

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:

GetValue

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:

ConvertValue

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:

TestCaseProperties

Here it is necessary to add two rows in the “Parameters”- section of the window – one for each shared variable.

AddParameters

By clicking the drop down menu “Module Variable”, the variables associated with this parameter (“varTemperature(GetValue)” and “varTemperature(Convert Value)”) can be checked.

EditParameters

Finally, the test suite should look like this:

Overview

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:

Report-1

Conclusion

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:

In This Article

Sign up for our newsletter

Share this article

Related Articles

Selenium-Performance-Testing-What-It-Can-Do,-What-It-Can't-and-Where-to-Draw-the-Line-blog-image

Selenium Performance Testing: What It Can Do, What It Can’t, and Where to Draw the Line

May 28, 2026
Key takeaways: Selenium gets pulled into performance testing more often than it should. The setup seems logical: you already have browser automation scripts that simulate real user workflows, so why not measure how long those workflows take? The problem is that Selenium was built...
Automated-Regression-Testing-Tools-Which-One-Actually-Works-for-Your-Team-new-blog-image

Automated Regression Testing Tools: Which One Actually Works for Your Team?

May 7, 2026
TLDR: The best automated regression testing tool depends on your application stack and team workflow. For desktop, web, and mobile testing in one platform, Ranorex, TestComplete, and Katalon are the strongest options. For modern web apps and code-first teams, Playwright, Cypress,...
Test-Case-Design-How-to-Build-Better-Automated-Tests-blog-image

Test Case Design: How to Build Better Automated Tests

May 5, 2026
Your quality assurance is only as good as your test case design: your testing efficiency, test coverage, and product quality are all directly impacted by it. In this guide, we’ll explore practical test case design techniques, review common preconditions, and learn how to build mo...