Objects in QF-Test variables – an overview

When working with variables in QF-Test, the biggest challenge so far has been to understand which variable is currently active with which value. Important here are the variable stacks – the manual explains their function in detail.

The status quo up to QF-Test 9

The values stored in variables used to be strings always. Other objects (e.g. numbers) were converted to a string when stored in a variable with rc.setLocal or rc.setGlobal and stored in the QF-Test main process. When read with rc.getInt or rc.getBool the value was then translated back.

Using this mechanism it is also possible to set a variable in an SUT script and then use its value in a server script or an If node (and vice versa). If you wanted to cache complex objects, you always had to work with the “global” script variables of a scripting language, and across process boundaries you had to use rc.fromSUTand rc.toSUT or rc.fromServer and rc.toServer.

After more than 20 years this simple understanding of values has reached its limits and has been extended with QF-Test 9: it is now possible to store arbitrary objects in QF-Test variables and thus return complex objects from a procedure, for example.

Ensuring backwards compatibility

First things first: We have invested a lot of effort to ensure backwards compatibility. The preexisting access methods in the run context return the same types, values can be stored in the same way and when things get complicated (for example when a non-serializable or very large object from an SUT script wants to be stored in a QF-Test variable), QF-Test falls back to the previously used string representation.

Object variables in variable tables

In QF-Test you can tell right away in any variables table (e.g. in the options dialog or in the debugger window) whether a variable value is a string or has a different type: In the first case, everything looks the same as before, i.e. only the string appears in the table. In the second case, the variable value is preceded by the type of the object in parentheses, e.g. (Boolean) true.

The type of a stored variable can also be changed here via the context menu.

Object variables in “Set variable”, “Return” and parameter tables

In case of the “Set variable” node and the “Return” node in a procedure, the type of the set or returned variable can now also be explicitly specified. This is done at runtime, i.e. when the node is executed, the character string specified as the value in the node is converted into the selected type.

In the same way, the type of the parameter can also be defined in parameter tables, for example in sequences – here too, the conversion takes place when the node is executed. The value of the parameter then appears in the table again with a type reference, for example: (as Number) 3.141. The “as” indicates that the conversion takes place at runtime.

Such a conversion can also be carried out everywhere a variable expansion takes place with the help of the special group “as”, the syntax looks like ${as:fromjson:[1,2,3,4]}.

Object variables via rc.getObjand rc.vars

The rc.getObj method can now be used to read the object value of a variable in a script or script expression. Analogous to the existing methods such as rc.getStr, rc.getNum or rc.getBool, the variable (with one parameter) or a group variable (property, with two parameters) is evaluated here and its value returned – in this case without conversion.

An expansion of nested variable expressions in the value only takes place automatically if the value is a string, otherwise it must be explicitly requested via the parameter expand=true.

The run context now also offers a practical shortcut to any variable object: instead of rc.getObj("variablename") you can now simply write rc.vars.variablename, and rc.groups.qftest.suite.file returns the File object of the current test suite.

Object variables and $(name)

When you use the familiar $ notation for variables, the object value of the variable is used for as long as possible: if the variable average has the value (double) 2.3, for example, the new variable would also have the type double for a “Set variable” node with the default value $(average). However, if you combine the variables with further text, e.g. My average: $(average), the string representation of the variable value is automatically used and the new variable becomes a string, as well.

As before, you cannot simply write $(name) == “John” as a check expression in an If node – the correct syntax would be "$(name)" == "John". But script expressions are preferably used without the $ notation, so it’s better to use rc.getStr("name") == "John" – or now rc.vars.name == "John".

Various small improvements

These changes to the QF-Test variable system also allowed us to integrate other long-awaited features into QF-Test 9: The standard procedures and the special “qftest”-group now return their values as objects, as seen above.

It is now also possible in many places to hide values in variables using the context menu and only evaluate them again at runtime with ${decrypt:...} without the true values appearing in the run log.

Also the “Start process” node now accepts a list object as a parameter, which makes it possible to implement start nodes with a variable number of parameters much more easily.

These are small things, but they all contribute to making working and testing with QF-Test even more comfortable.

Outlook

If you have made it this far, you will have noticed that the topic is complex and certainly cannot be covered exhaustively here.

The developers behind QF-Test will provide details in an upcoming special webinar on the topic of object variables – and the newly redesigned QF-Test manual also explains variables in detail.