In the previous section we saw how easy it is to insert verification points during the recording of test scripts. Verification points can also be inserted into existing test scripts, either by setting a breakpoint and using the Squish IDE, or simply by editing a test script and putting in calls to Squish's test functions such as test.compare and test.verify.

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 14.20.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. In the previous section we showed how to use the Squish IDE to insert verifications during recording. Here we will first show how to use the Squish IDE to insert verifications into an existing test script, and then we will show how to insert a verification 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 two—we will verify that the "Jane Doe" entry's email address and phone number match the ones entered, and put the verifications immediately after the ones we inserted during recording.

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 35. 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 follows the 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". The screenshot shows the verifications that were entered using the Squish IDE during recording. Our additional verifications will follow them. (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 35, 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 (Section 17.1.2.3).

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—the Squish Test Management Perspective (Section 17.1.2.2) (which is the Perspective that the Squish IDE starts with, and the one we have seen in all previous screenshots), Squish Test Debugging Perspective (Section 17.1.2.3), and Squish Spy Perspective (Section 17.1.2.1). 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. In practice, Squish will automatically change perspective to reflect the current situation, so it isn't really necessary to change perspective manually. 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 the Squish IDE automatically changes to the Squish Test Debugging Perspective (Section 17.1.2.3). The perspective shows the Variables view (Section 17.2.18), the Editor view (Section 17.2.6), the Debug view (Section 17.2.5), the Application Objects view (Section 17.2.1), and the Properties view (Section 17.2.11), Methods view (Section 17.2.8), and Test Results view (Section 17.2.15).

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 (Section 17.2.11) as the screenshot shows.

Picking an object to verify in the Application Objects view

The normal Squish Test Management Perspective (Section 17.1.2.2) 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 of the item in row 0 and column 0 has the value “Jane”; we already have a verification for this that we inserted during recording. Scroll down so that you can see the item in row 0 column 2: this is the email address. To make sure that this is verified every time the test is run, click the “item_0/2” item in the Application Objects view (Section 17.2.1)to make its properties appear, and then click the text property to check its check box. When we check it the Verification Point Creator view (Section 17.2.19) 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 one more thing to be verified.

Scroll down and click the “item_0/3” item in the Application Objects view (Section 17.2.1); then click its text property. Now both verifications will appear in the Verification Point Creator view (Section 17.2.19) 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, an email address of “jane.doe@nowhere.com” and phone number of “555 123 4567”. 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 additional test results—as the screenshot shows—one of which we have expanded to show its details. (We have also selected the lines of code that Squish inserted to perform the verifications—notice that the code is structurally identical to the code inserted during recording.)

The newly inserted verification points in action

These particular verification points generate four tests comparing the forename, surname, email, and phone number of the newly inserted entry.

Another way to insert verification points is to insert them in code form. In theory we can just add our own calls to Squish's test functions such as test.compare and test.verify anywhere we like in an existing script. In practice it is best to make sure that Squish knows about the objects we want to verify first so that it can find them when the test is run. This involves a very similar procedure to inserting them using the Squish IDE. First we set a breakpoint where we intend adding our verifications. Then we run the test script until it stops. Next we navigate in the Application Objects view (Section 17.2.1) until we find the object we want to verify. At this point it is wise 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 number of addresses present in the QTableWidget after reading in the MyAddresses.adr file, then after the new address is added, and finally after the first address is removed. The screenshot shows two of the lines of code we entered to get one of these three verifications, plus the results of running the test script.

Manually entered verification points in action

When writing scripts by hand, we use Squish's test module's functions to verify conditions at certain points during our test script's execution. 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—in this case the QTableWidget's rowCount property—and verify that the value is what we expect it to be using the test.verify function. (Incidentally, we got the name for the object from the previous line so we didn't need to set a breakpoint and manually add the table's name to the Object Map to ensure that Squish would remember it in this particular case because Squish had already added it during the test recording.)

Here is the code we entered manually for the first verification 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. (For the other verifications we just did calls to the test.verify function—or to the test.compare function for Tcl since it's more convenient—reusing the table object reference we obtained in the code shown below.)

    test.verify(numberOfRows() == 125)

    test.verify(numberOfRows() == 125); 

    test::verify(numberOfRows() == 125); 

    test compare [numberOfRows] 125

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 4.5) section, and further examples are in the User Guide (Chapter 14).

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