Squish supports two kinds of verification points, those that verify that a particular condition holds—known as "Object Property Verifications", and those that verify that two images match—known as "Screenshot Verifications". Although the screenshot verifications are very impressive, by far the most commonly used kind are object property verifications, and it is these that we will cover in the tutorial. (See How to Do Screenshot Verifications (Section 15.3.2) for coverage of screenshot verifications.)

In fact, object property verification points (which we'll just call "verification points" in the rest of the tutorial), are simply calls to the test.compare() function, with two arguments—the value of a particular property for a particular object, and an expected value. We can manually insert calls to the test.compare() function in a recorded or hand written script, or we can get Squish to insert them for us using the IDE. Here we will show how to use the IDE; and then we will look at the code inserted by the IDE since that's what we would enter ourselves if we chose to do it by hand—and in the next section we will do it by hand.

Before asking Squish to insert verification points, it is best to make sure that we have a list of what we want to verify and when. There are many potential verifications we could add to the tst_general test case, but since our concern here is simply to show how to do it, we will only do one—we will verify that at the end, just before closing the AUT, the first entry in the address book is the "Jane Doe" entry that is inserted in the course of the test. (It is originally inserted as the second item, but since the first item gets deleted, it ends up being the first item.)

To insert a verification point using the IDE we start by putting a break point in the script (whether recorded or manually written—it does not matter to Squish), at the point where we want to verify.

The Squish IDE showing the tst_general test case with a breakpoint

As the above screenshot shows, we have set a breakpoint at line 32. This is done simply by right-clicking the line number and then clicking the Toggle Breakpoint menu item in the context menu. We chose this line because it immediately follows script lines where the first address is removed, so at this point (just before invoking the File menu to close the application), the first address should be that of "Jane Doe". (Note that your line number may be different if you recorded the test in a different way, for example, using keyboard shortcuts rather than clicking menu items.)

Having set the breakpoint, we now run the test as usual by clicking the Run Test button, or by clicking the Squish|Run Test menu option. Unlike a normal test run the test will stop when the breakpoint is reached (i.e., at line 32, or at whatever line you set), and Squish's main window will reappear (which will probably obscure the AUT). At this point the Squish IDE will automatically switch to the Squish Test Debugging perspective.

Perspectives and Views

The Squish IDE works just like the Eclipse IDE. This provides a much more sophisticated user interface than the old Squish Classic IDE. If you aren't used to Eclipse it is crucial to understand one key concept: Views and Perspectives. In Eclipse (and therefore in the new Squish IDE), a View is essentially a child window (perhaps a dock window, or a tab in an existing window). And a Perspective is a collection of Views arranged together. Both are accessible through the Window menu. The Squish IDE is supplied with three Perspectives—Squish Test Management (which is the Perspective that the Squish IDE starts with, and the one we have seen in all previous screenshots), Squish Test Debugging, and Squish Spy. You can change these Perspectives to include additional Views (or to get rid of any Views that you don't want), and you can create your own Perspectives with exactly the Views you want. So if your windows change dramatically it just means that the Perspective changed; you can always use the Window menu to change back to the Perspective you want. Other than this, the Squish IDE works in a very similar way to the Classic IDE, although it has a lot more features, and is easier to use once you've got used to it.

As the screenshot below shows, when Squish stops at a breakpoint and the Squish IDE changes to the Squish Debugging perspective, the perspective shows the Variables view, the Editor view, the Debug view, the Application Objects view, and the Properties, Methods, and Test Results views.

To insert a verification point we can expand items in the Application Objects view until we find the object we want to verify. In this example we want to verify the QTableWidget's first row's texts, so we expand the “Address Book - MyAddresses_adr” item, and its child items until we find the QTableWidget, and within that the item we are interested in. Once we click the item object its properties are shown in the Properties view as the screenshot shows.

Picking an object to verify in the Application Objects view

The normal Squish Test Management perspective can be returned to at any time by choosing it from the Window menu (or by clicking its toolbar button), although the Squish IDE will automatically return to it if you stop the script or run it to completion.

Here, we can see that the text property has the value “Jane”. To make sure that this is verified every time the test is run we just have to click the text property to check its check box. When we check it the Verification Point Creator view appears as shown in the screenshot.

Choosing a property value to verify

At this point the verification point has not been added to the test script. We could easily add it by clicking the Insert button (next to the Scriptified Properties VP combobox). But before doing that we'll add a few more things to be verified.

Click the row and column properties' checkboxes. Then click the second item (the item_0/1 object in the Application Objects view), and click this item's text, row, and column properties' checkboxes. All these will appear in the Verification Point Creator view as the screenshot shows.

Choosing several property values to verify

We have now said that we expect these properties to have the values shown, that is, a text of “Jane” and a row and column of 0, and a text of “Doe” and a row of 0 and a column of 1. We must click the Insert button to actually insert the verification point, so do that now.

We don't need to continue running the test now, so we can either stop running the test at this point (by clicking the Stop toolbar button, or we can continue by clicking the Resume button.)

Once we have finished inserting verifications and stopped or finished running the test we should now disable the break point. Just right click the break point and click the Disable Breakpoint menu option in the context menu. We are now ready to run the test without any breakpoints but with the verification points in place. Click the Run Test button. This time we will get some test results—as the screenshot shows—two of which we have expanded to show their details. (We have also selected the lines of code that Squish inserted to perform the verifications.)

The newly inserted verification points in action

These particular verification points generate six tests, one to compare the row, another the column, and another the text in the table, for each of the QTableWidget's first rows' first two items.

Another way to insert verification points is to insert them in code form. This involves a very similar procedure as using the Squish IDE. First we set a breakpoint where we intend adding our verifications. Then we run the test script until it stops. Then we navigate in the Application Objects view until we find the object we want to verify. At this point it makes sense to right-click the object we are interested in and click the Add to Object Map context menu option. This will ensure that Squish can access the object. Then right click again and click the Copy to clipboard (Symbolic Name) context menu option—this gives us the name of the object that Squish will use to identify it. Now we can edit the test script to add in our own verification and finish or stop the execution. (Don't forget to disable the break point once it isn't needed any more.)

Although we can write our test script code to be exactly the same style as the automatically generated code, it is usually clearer and easier to do things in a slightly different style, as we will explain in a moment.

For our manual verifications we want to check the email address and row and column of the last row in the QTableWidget. The screenshot shows the four lines of code we entered to get these three verifications, plus the results of running the test script.

Manually entered verification points in action

As the screenshot (and the code snippets below) show, we begin by retrieving a reference to the object we are interested in. Using the waitForObject() function is standard practice for manually written test scripts. This function waits for the object to be available (i.e., visible and enabled), and then returns a reference to it. (Otherwise it times out and raises a catchable exception.) We then use this reference to access the item's properties, using them in three calls to the test.compare() function to perform the verifications we want. When writing scripts by hand, we use this function (and similar ones) to verify conditions at certain points during our test script's execution. (Incidentally, we got the name for the object simply by pasting from the clipboard since we copied the object's symbolic name to the clipboard from the Application Objects view. We also added the object—item_124/2—to the Object Map so that Squish would remember it.)

Here is the code we entered manually for all the scripting languages that Squish supports. Naturally, you only need to look at the code for the language that you will be using for your own tests.

    tableItem = waitForObject(":File.124_2_QModelIndex")
    test.compare(tableItem.text, "z.glen@bush.eu")
    test.compare(tableItem.row, 124)
    test.compare(tableItem.column, 2)

    var tableItem = waitForObject(":File.124_2_QModelIndex");
    test.compare(tableItem.text, "z.glen@bush.eu");
    test.compare(tableItem.row, 124);
    test.compare(tableItem.column, 2);

    my $tableItem = waitForObject(":File.124_2_QModelIndex");
    test::compare($tableItem->text, "z.glen\@bush.eu");
    test::compare($tableItem->row, 124);
    test::compare($tableItem->column, 2);

    set tableItem [waitForObject ":File.124_2_QModelIndex"]
    test compare [property get $tableItem text] "z.glen@bush.eu"
    test compare [property get $tableItem row] 124
    test compare [property get $tableItem column] 2

The coding pattern is very simple: we retrieve a reference to the object we are interested in and then verify its properties using one of Squish's verification functions. And we can, of course, call methods on the object to interact with it if we wish.

We will see more examples of manually written code shortly, in the Creating Tests by Hand (Section 5.4) section, and further examples are in the User Guide (Chapter 15).

For complete coverage of verification points, see How to Create and Use Verification Points (Section 15.3) in the User Guide (Chapter 15).