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
APPLICATION
variable 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 |