Tutorial as a video version, where we guide you step by step through QF-Test...
Next, we want to explore the variable bindings table and see how it can be used for debugging purposes. For this reason do not correct the faulty value of the procedure call we added in the last section, but let us find out more about debugging.
In the next steps we want to have QF-Test pause the test execution at the procedure call. Then we will step into the procedure and, while doing so, have a look at the variable bindings table. Finally, we will navigate directly from the variable bindings table to the faulty procedure call and correct the parameter value.
|Figure 6.8: Variable bindings stack showing incorrect value|
As you step into the procedure, first the row 'Call procedure: checkFinalPrice' and with the next step the row 'Procedure: checkFinalPrice' appear at the top of the table.
Now the variable
price shows on two different levels of the variable bindings table:
In the 'Call procedure: checkFinalPrice' row and the 'Procedure: checkFinalPrice' row on the fallback stack.
Since we did not adapt the value of the parameter passed to the procedure, neither of
the two values bound to the
price variable is correct.
QF-Test lets you change the values of the variables interactively in the variable bindings table when you are in debugging mode. You can even add new variables or delete them. However, changes to variable values in the variable bindings table are not persistent. They only last as long as the variable is on the stack (variable bindings table). In our case, if we changed the price value, as long as the procedure is being executed.
The parameter value in the procedure call will not be altered by changing the current value of the variable in the variable bindings table. To do so you have to navigate to the 'Procedure call' node and change it there.
To get there quickly, you just double-click the procedure call in the variable binding table (second row). This feature is particularly useful when debugging more complex tests where the node you want to jump to is not directly visible in the test suite window. You can invoke it via right-clicking the row and selecting »Jump to node in test suite« from the pop-up menu, too.
When checking the variable bindings table you will notice that the current value has not changed. This is hardly surprising as we have not yet executed the procedure call again. Only, test execution is already past the procedure call. Fortunately, QF-Test has another very useful debugging feature to set back (or forward) test execution to some node: »Continue execution from here«, which can be invoked either via the pop-up menu of the node you want to make the current node or by pressing [Ctrl-,] after selecting the node.
In order to try out the newly set value:
|Figure 6.9: Continue Execution from here|
When checking the variable bindings table you will find that the top two rows have disappeared. This is because now we exited the procedure (even though 'backwards') and therefore the procedure call and all its variable bindings was taken off the call stack.
The test run should finish without error.
Note As the variable bindings table is very useful when looking for incorrect variable values you will also find a copy of it in the run log whenever an error or exception is logged. It is written to the subnode 'Stack trace' of the node causing the error, showing the variable values at the time the error occurred.
Locate the current Node: Sometimes during debugging you will navigate far away from the current node where execution stopped and eventually want to get back to it again. The easiest way to do so is by pressing the "Locate Current Node" button or select the »Debugger«-»Locate Current Node« menu option to cause the debugger to "select" the current node.
|Last update: 5/31/2023|
Copyright © 2002-2023 Quality First Software GmbH