Day in, day out, our diligent support team reads and answers the questions of our customers coming in by mail. To pass on some of this collected support wisdom, here are some of the questions we were asked in the last weeks, as well as our answers.
How to « Check text » of a data driver item instead of a component
One of our customers had a data driver set up to query their database, and they wanted to use a « Check text » node to check the queried data instead of checking a component.
Unfortunately, the « Check text » step always relates to a GUI component as source. But you can easily achieve the same thing with a short SUT script:
rc.checkEqual(
rc.lookup("variableWithDataFromDataDriver"),
rc.lookup("variableWithExpectedValue"),
"Check if data driver returns expected value"
)
How to compare two data sources to each other
This one also has to do with data drivers.
A customer wanted to check database values against another dataset (in a data table). They noticed that nesting data drivers or placing two sources in one data driver did not have the desired effect. (Placing two sources in a data driver is defined as iterating over the cross product of both data sources, which is cool but not what we’re looking for here).
So, is there a way to iterate through the rows of a database using the iterator from the data table? Yes! To compare the elements in a data driver against elements from a database query, you can proceed like this:
Before iterating over the actual data, use the procedure qfs.database.executeSelectStatement from the standard library to load the reference data into a property group « expectedValues ».
Then, inside the data driver loop you can perform the checks like this:
rc.checkEqual(
rc.lookup("variableWithDataFromDataDriver"),
rc.lookup("expectedValues", "dataColumn:" + rc.lookup("counter")),
"Check if data driver returns expected value"
)
How to filter error messages from the QF-Test terminal
Another customer had a question about an error message (caused by their SUT) filling up the QF-Test terminal and making them miss other important log information.
Even though QF-Test can not stop errors in an SUT it is possible to instruct QF-Test to filter certain messages from the terminal output via an output filter.
This can be done by adding the following doctag to the comment field of your « Start Web Engine » node:
@outputFilter drop [regular expression matching part of the message to filter]
How to check if a variable is set at runtime
The last customer question for today is about variables. A customer wondered how to check if a QF-Test variable has previously been assigned a value during a test run.
In general, accessing such an « unbound » variable will trigger an exception of type « UnboundVariableException ». You could always use a « Try » and « Catch » node to handle this exception. But there is a more elegant way for most use cases.
Instead of accessing the variable with $(myvariable) you can use the special default group to define a fallback value in case the variable is not set: ${default:myvariable:MyFallbackValue}.
That’s it for today! If you have your own question about using QF-Test you need answered, feel free to drop a line to our support team.