You are here: Chapter 4: Writing and Configuring Test Scripts > Variables


Variables allow to parametrize test scripts, create reusable pieces of code and even pass values from outside. The scripting framework also uses the mechanism of variables to produce and transfer data resulting from script compilation or execution. The latter function will be discussed later on. This topic focuses on user defined variables.

Variables can be defined in test scripts through the Var and Eval commands. Each command may contain one or more variable definitions. Each variable is uniquely identified by a case sensitive variable name. The name should not consist just of digits because it could conflict with procedure arguments (will be discussed in another topic). It is also recommended not to use names starting with underscore which are typically used for predefined variables (will be also discussed in another topic). If the variable name or value contains spaces, it must be enclosed with double quotes.

As a convention we suggest to design global variable names in upper case without spaces (underscores may be optionally used instead). This improves readability of the code. We also recommend to enclose the variable value and all its calls always with double quotes even when it doesn't contain any spaces at the moment. This will make the script robust against unexpected space characters appearing in variable values.

Variables can be either local or global. Global variables are defined anywhere in the main script body, usually at the beginning. They are available from the point of their definition until the end of the script. Their value may be changed any time through repeated call of the Var or Eval command. Local variables are typically defined inside a structured block of code (either a procedure, if/else statement or the for loop). They serve as temporary storage and they exist just within the block (or any nested blocks on the lower level). As an example see the mywait variable in the sample script on the left. For more details see the language specification.

When a script is compiled or executed, the script interpret will replace all calls in form of {varname} in each command line with the variable value. If the variable doesn't exist, the text is left as it is (there's no "default value"). From this point of view variables behave rather like macros. Replacement of variable calls is recursive and supports nested variable calls, such as for example {MY_VARIABLE{INDEX}} where the INDEX variable is replaced first and the expression is processed once more to resolve the resulting variable name.

Global variable values can be fixed to a particular value through the -v/--variable CLI option. This provides a mechanism to pass values from outside of T-Plan Robot Enterprise. For example, the sample script calc.tpr on the left starts a Windows application defined by the APPLICATIONvariable and takes a screen shot. If you execute it as it is, it will start the system calculator. To execute the script automatically and make it start Internet Explorer instead run T-Plan Robot Enterprise as follows:

java -jar robot.jar -c <desktop> -p <password> -r calc.tpr -v APPLICATION=iexplore

The -v option sets the APPLICATION variable value to "iexplore". This value will remain constant for the whole time of T-Plan Robot Enterprise execution and all attempts to redefine the value through Var or Eval will be ignored. As there may be any number of -v options on the command line, you may also set the application start timeout to a higher value (10 seconds/10000 milliseconds) as follows:

java -jar robot.jar -c <desktop> -p <password> -r calc.tpr -v APPLICATION=iexplore -v TIMEOUT=10000

Variables can be tracked during script execution or after compilation through the Variable Browser GUI component.


12 December 2014

Copyright © T-Plan Ltd.

Version 1.0