Verification Point Creator
The Verification Point Creator view appears automatically when we check a property's checkbox in the Properties view (unless it is already visible). This view is used to accumulate a list of one or more property verifications ready to be inserted into a test case's script.
The Verification Point Creator view
The verifications listed in the Verification Point Creator view are only inserted into the test script that is being recorded (or that is being played and is stopped at a breakpoint), if the Insert button (at the top-right) is clicked.
In the example shown in the screenshot, clicking the Insert button would result in the following lines being inserted into the test script (assuming we are using Python—the code for other languages is very similar):
test.compare(waitForObjectExists(":Invoice:_QComboBox").currentText, "AXV-12200") test.compare(waitForObjectExists(":This Payment:_QSpinBox").value, 350) test.compare(waitForObjectExists(":Make Payment.Credit Card_QRadioButton").checked, True)
If we wanted to do these same verifications in hand written code we could write the same as the above, but in practice we do things in a different style by hand and would instead do this:
comboBox = waitForObject(":Invoice:_QComboBox") test.compare(comboBox.currentText, "AXV-12200") spinBox = waitForObject(":This Payment:_QSpinBox") test.compare(spinBox.value, 350) radioButton = waitForObject(":Make Payment.Credit Card_QRadioButton") test.verify(radioButton.checked)
We can invert the meaning of a verification shown in the view by checking the Expected Failure checkbox and changing the value to one we do not expect. To continue the example shown in the screenshot, we could set the radio button's
checked value to "false" and check the associated Expected Failure checkbox. This would make Squish generate a call to the Boolean test.xcompare(value1, value2) function rather than to the Boolean test.compare(value1, value2) function and to use a value of
false in the comparison.
If we change our minds and don't want to insert a particular verification we can simply click its associated Delete button. And if we want to delete a verification after it has been inserted we just need to delete the one or two lines of code that do the verification in the test script's code.
By default verifications are inserted as "Scriptified Properties VP"s—this just means that they are inserted as code as shown above. This is by far the most convenient way to insert verifications because it makes them easy to read and easy to modify or delete.
It is also possible to insert a verification as a "Properties VP"—this creates a new resource in the Test Suites view's Test Case Resources list (in the VPs tab) called "VP1" (or "VP2" if VP1 exists, etc.). Such verifications are inserted into the test script as calls to the Boolean test.vp(name) function with the name of the verification point being passed as the sole parameter. The name can be changed by invoking the context menu on the verification point in the Test Suites view's Test Case Resources list—if you do this, make sure that the name used in the call to the Boolean test.vp(name) function is the same. If you delete a verification from the Test Suites view's Test Case Resources list, you must also delete any associated calls to the Boolean test.vp(name) function that refer to the deleted verification.
Squish supports a third kind of verification, Screenshot VP as the screenshot below illustrates.
The Verification Point Creator view with a Screenshot VP
To create a screenshot verification double-click the object you want a screenshot of in the Application Objects view. This could be the entire application (i.e., if you click the top-level object), or just one widget (as here where we have double-clicked a spinbox). Screenshot verifications are very similar to Property verifications: they appear as resources in the Test Suites view's Test Case Resources list and are invoked by a call to the Boolean test.vp(name) function. Just as with Property verifications they can be renamed (in which case the name used in the Boolean test.vp(name) function call must be changed to match), or deleted (in which case the Boolean test.vp(name) function call must also be deleted).
In general it is much more reliable doing property verifications that screenshot verifications since the latter can be affected by all kinds of irrelevant influences. For example, a change to a computer's theme might mean that a different font is used or that widget borders are thinner, thicker or differently colored than before, and so on. So, here for this example, it is much better to verify the amount (350) than to use a screenshot verification.