Define test and variables

First, define the steps of the data-driven test. Then, define the required variables for this scenario. Also, find out how to manage variables in Ranorex Studio.

Variables are one of the key parts of data-driven testing. They are the placeholders for values you want to feed your test, either from data sources or parameters. In Ranorex Studio, we differentiate between three types of variables: Action variables, their subtype validation variables, and repository variables.

 

As usual, use the Ranorex Studio Demo Application for the example. It has a database function that you can test. Testing a database is a common real-world application of a data-driven test.

The test contains the following steps:

1. Start the Demo App and click the Test database tab.

2. Add an entry to the database by clicking Add entry.

3. Repeat until there are 8 entries in the database…

4. After each entry, validate that the Number of entries updates correctly.

5. Close the Demo App.

Sample solution and prepared modules

The sample solution already contains all the modules with the necessary actions for the steps above. They are organized in a simple test suite. This serves as our starting point for the next step: replacing constant values in several modules with variables.

1. Module browser with recording modules structured in folders

2. Test suite with a ready-to-run database test scenario

Action variables replace a constant value in a component or property of an action, for example, the specific text string in a Key sequence action. Action variables are limited to the recording module they’re defined in.

First, let's replace the constant text values in the respective actions for entering the first name, last name, and age of a person in the Demo App database.

To replace a constant value with a variable:

1. Open the drop-down list for the constant value you want to change and click As new variable…

2. Name the variable so you can easily identify what value it is a placeholder for and click OK.

3. The variable appears in the action table in green, replacing the constant value.

4. Repeat the above process for the last name (InsertName module) and the age (InsertAge module).

The final result should look like this:

1. Variable $txtFirstName replacing the constant value ‘John’ for the first name

2. Variable $txtLastName replacing the constant value ‘Public’ for the last name

3. Variable $intAge replacing the constant value ’48’ for age

Aside from making action value variables, data-driven testing often involves creating repository variables. Repository variables replace a certain part of an item’s RanoreXPath, the defining attribute, with a variable. You can make any repository item variable this way. Repository variables are available in the repository they were defined in and all modules that reference this repository.

For this example, make a list selection and radio buttons variable. These are repository items where it often makes sense to make them variable because they are usually part of a selection process with multiple options.

 

Reference

---

For more information on RanoreXPath, go to Ranorex Studio advanced >  RanoreXPath

 

Make a list selection variable

Here, let's make the repository item for the Department list selection variable.

In the module SelectDepartment of the sample solution, the Click action is linked to a constant repository item that points to the Project Management entry in the list. In the item’s RanoreXPath, the attribute @text=’Project Management’ is responsible for this.

Let's replace the constant attribute value Project Management with the variable $lstDepartment so the Click action is performed on whatever list entry our future data source specifies.

To define the variable:

1. Right-click the second Click action and choose Make repository item variable…

2. Ranorex Spy opens with the constant value of the text attribute already highlighted. Click the variable symbol next to it.

3. Name the variable so you can easily identify what repository item it refers to and click OK.

4. In the yellow bar, click Apply.

5. In the repository, you can now see the variable in the item’s RanoreXPath.

1. 1. Repository variable $lstDepartment replaces the constant value for department selection.

Make radio buttons variable

Here, let's make the repository item for the Gender selection variable.

In the module SelectGender of the sample solution, the Click action is linked to a constant repository item that points to the radio button for Male. In the item’s RanoreXPath, the attribute @controlname=’rdbMale’ is responsible for this.

Let's now replace the constant attribute value in the RanoreXPath of this repository item with a variable ($selGender) so the Click action is performed on whatever Gender radio button our future data source specifies.

 

To define the variable:

1. Right-clickthe Click action and choose Make repository item variable…

2. Ranorex Spy opens with the constant value of the text attribute already highlighted. Click the variable symbol next to it.

3. Name the variable so you can easily identify the repository item it refers to and click OK.

4. Click Apply.

5. In the repository, you can now see the variable in the item’s RanoreXPath.

1. 1. Repository item representing the Gender radio button selection with variable $selGender

Our example test includes a step that validates whether the database counter updates correctly as entries are added. For this validation to work, we need to make it variable.

So, we’ll replace the constant Match value of the validation action in the ValidateEntries module with a variable.

To define the variable:

1. Open the drop-down list for the Match value and click As new variable…

2. Name the variable so you can easily identify the value it is a placeholder for and click OK.

3. The variable appears in the action table in green, replacing the constant value.

The default value of a variable is the value that is used when no data source is available. This is the case when running a recording module from the recording module view, for example. Therefore, you should always make sure to define a meaningful default value.

You can view the status of variables and manage them in different places: the data binding pad gives you a detailed overview of the status of all variables in a recording module, while the VARIABLES… dialog allows you to add variables and edit them.

Data binding pad

When opened in the recording module view, the data binding pad shows the status of action, repository, or code variables in this recording module and their default values. The data binding pad reflects the icons and status designations from the VARIABLES… dialog. These are explained in the next topic below.

1. If the recording module contains variables that are only used in code, then these initially appear under Not in use. The button Identify code variables identifies them and causes them to be displayed under In use in code.

VARIABLES… dialog

This dialog shows you variable status and also lets you add and edit variables.

To open the dialog for managing variables:

a. For action variables, open the recording where they are defined and click VARIABLES….

The variable management dialog opens:

1. Variable status, Name, and corresponding Default value

2. Variable editor toolbar

• • Options to copy/paste a variable to/from the clipboard.
  • Option to add a new variable directly.
  • Option to remove unused variables (variable cleanup).
  • (Action variable dialog only) Option to copy a repository variable to the current recording module, where it becomes an action variable.

3. Variable status legend
   

• • Variable in use: A variable is used, for example, it is assigned to an action. Does not indicate whether the variable is bound/unbound to a data source.
  • (Action variable dialog only) Variable in use from repository: Same as previous, but for repository variables that are in use in the action table through a linked repository item.
  • Variable not in use: Variable is defined, but not assigned to an action item. Does not indicate whether the variable is bound/unbound to a data source.

You now defined all the variables we need for our data-driven test. When you switch to the test suite view, you can now see the number of variables defined per module. Note they are still unbound, i.e. they have not been assigned a data source.

In the next chapter, we’ll define this data source and assign it to our test case. We’ll also discuss the options for managing data sources.

1. The test suite view displays the defined, but currently unbound variables