10. July 2019
Veni, vidi, variavi – Using Variables
There‘s no way around using variables if a test-suite has to to be flexible, reusable, and elegant. But where are variables set? Which value of the variable is used if I defined multiple ones at different positions? And how can I find out? This article aims to answer these questions.
Which value is used?
Variables are saved on two stacks: the primary stack and the secondary stack, also called fallback stack. The second-mentioned is used for default-values, that are only called if there is no value found on the primary stack. Those stacks are not hidden, but can be viewed anytime – e.g. by pausing the test execution or debugging. Also the stacktrace is attached to the run-log in case of an error/exception (Fig. 1).
When the value of a variable is needed, QF-Test will try to find it in the stack. It will start at the „top“ of the primary stack, going one layer „lower“ if it does not find a binding for the variable. The default values on the secondary stack are only taken into account if direct binding is found in the primary stack.
To illustrate this, take a look at (Fig. 2). Here, „Variable1“ was bound to a default value in „ExampleProcedure“. However, when this procedure is called, the value is explicitly set to „not default“. This binding ranks higher and overwrites the default value on the fallback stack.
How are variables set?
There are many ways to set variables. At Edit → Options → Variables latter can be set, some even before a test-suite exists. The stacktrace shows which binding (System, Suite Command line, Globals) ranks the highest.
Every node that has the attribute „Parameter default values“ allows to set default values on the fallback stack.
The most obvious choice is the „Set variable“-node, of course. But there are also multiple ways to read values from our system under test, like the text in a table cell. The simplest way to achieve this is to record a mouse click on the element that contains the value, then transform the node into a „Fetch text“-node. The result of the fetch can be bound to a variable and used later. (Fig.3) shows such a node and its attributes. But what does „Local variable“ mean?
To keep it short and simple: Global variables exist from their creation to the end of time (that being the end of the QF-Test process or until they are explicitely deleted). Also, they are not just bound to your current test-suite. Thats an easy to understand concept, but it also can lead to easy to avoid mistakes, where a variable is unintentionally changed somewhere else or not reset after an earlier test execution.
In the stack, local variables can be found bound to the node on which they are valid. The respective node can be found by debugging, as shown later. If the variable is set in a test-case, for example, its value exists in the scope of this test-case and all test-steps, sequences etc. within it. After this node is done and disappears from the stacktrace, all of the local variables that belonged to it cease to exist. This way side effects in huge and complex test-suites can be avoided.
At last there are scripts. A variable can easily be set in a Server- or SUT-script, as you can see in (Fig. 4).
Keep in mind that all variables in QF-Test are saved as Strings! So don‘t forget to either convert the variables to your desired type (e.g. for calculations), or to read them using the correct rc-Method, like in (Fig. 4).
Which value is used for the variable?
It‘s easy to lose track of which variable is assigned to which value when working with default values, multiple nested procedure calls and global variables. Luckily there are multiple possibilities to find out the current value of a variable, two of which are presented here:
1. Everyones favorite „print-debugging“
Simply insert a script with qf.println(rc.lookup("name_of_your_variable")) to print the value of the variable in the terminal. „qf.print“ got introduced with version 4.6 and works in every scripting language – for older version use the language-specific „print“-Method. You can log the value by using „rc.logMessage“ or „rc.logError“. Just be a good boy scout and clean up those print-statements after you are done.
2. Normal debugging.
Ctrl+F8(Mac: ⌘+⇧+B ) enables breakpoints in your suite. QF-Test will stop the test-execution at those breakpoints and switch to debugging mode. Now, these helpful buttons (Fig. 5) enable you to execute nodes step-by-step and a tab for „Variables“ showing the current stacktrace appears next to the terminal (Fig. 6). As mentioned before, the highest binding of a variable is its currently used value.
