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 three kinds of verification points: those that verify that a particular condition holds—known as "Object Property Verifications"; those that verify that an entire table has the contents we expect—known as "Table 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 also How to Create and Use Table Verifications (Section 13.20.2) and How to Do Screenshot Verifications (Section 13.20.3).)

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 before 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 19. 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 finishing), 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 precede 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 Run|Run Test Case menu option. Unlike a normal test run the test will stop when the breakpoint is reached (i.e., at line 19, 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 16.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 16.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 16.1.2.3), and Squish Spy Perspective (Section 16.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 16.1.2.3). The perspective shows the Variables view (Section 16.2.18), the Editor view (Section 16.2.6), the Debug view (Section 16.2.5), the Application Objects view (Section 16.2.1), and the Properties view (Section 16.2.11), Methods view (Section 16.2.8), and Test Results view (Section 16.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 or we can use the Pick toolbar button to pick the object we are interested in in the AUT.

Picking an object to verify in the Application Objects view

The normal Squish Test Management Perspective (Section 16.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.

In this example we want to verify the first row's email address and phone number (since we already have verifications for the forename and surname). It is easiest to find them in the AUT rather than navigate the Application Objects view (Section 16.2.1). First click the Pick toolbar button then click the first row's email entry (i.e., “jane.doe@nowhere.com”) in the AUT. Now back in the Squish IDE in the Properties view (Section 16.2.11) check the innerText property.

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.

Click the Pick toolbar button then click the first row's phone number. Now back in the Squish IDE in the Properties view (Section 16.2.11) check the innerText property. Now both verifications will appear in the Verification Point Creator view (Section 16.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 16.2.1) until we find the object we want to verify—or we click the Pick toolbar button and click the object in the AUT. 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 <table> after loading the initial addresses, then after the new address is added, and finally after the second address is removed.

The original test recording does not store details of the <table> in Squish's Object Map because they aren't needed for the test we recorded. But for us to count the number of rows we must have access to the table. This is easily done. First we add a breakpoint to one of the lines (it doesn't matter which—so long as the list of addresses is showing at the time the breakpoint happens—we used line 4). Then, we run the test and when it is stopped by the breakpoint we click the Application Objects view (Section 16.2.1)'s Pick toolbar button. Then we click the entire table in the AUT. (This can be slightly tricky—just hover until the red outline includes the whole table.) Back in the Squish IDE we right-click the table in the Squish IDE's Application Objects view (Section 16.2.1) and click the Add to Object Map context menu option. Then we right-click again and click the Copy to clipboard (Symbolic Name) context menu option—then paste this name into the test script where it will become part of a numberOfRows function. (Don't forget to remove the breakpoint afterwards, since it isn't needed anymore.)

The screenshot shows the line of code we entered to get one of these three verifications; it also shows the results of running the test script. (We will see the tiny custom numberOfRows function in a moment.)

Manually entered verification points in action

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 all the row count verifications we just did calls to the test.verify function—or to the test.compare function for Tcl since it's more convenient.)

    test.verify(numberOfRows() == 125)

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

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

  Test.verify(numberOfRows == 125)

    test compare [numberOfRows] 125

And here is the custom numberOfRows function that our verification depends upon.

def numberOfRows():
    table = waitForObject(":DOCUMENT.HTML1.BODY1.DIV1.DIV1.FORM1.TABLE1")
    results = table.evaluateXPath(".//TR/TD[@class='surname']")
    return results.snapshotLength

function numberOfRows() {
    var table = waitForObject(":DOCUMENT.HTML1.BODY1.DIV1.DIV1.FORM1.TABLE1");
    var results = table.evaluateXPath(".//TR/TD[@class='surname']");
    return results.snapshotLength;
}

sub numberOfRows
{
    my $table = waitForObject(":DOCUMENT.HTML1.BODY1.DIV1.DIV1.FORM1.TABLE1");
    my $results = $table->evaluateXPath(".//TR/TD[\@class='surname']");
    return $results->snapshotLength;
}

def numberOfRows
  table = waitForObject(":DOCUMENT.HTML1.BODY1.DIV1.DIV1.FORM1.TABLE1")
  results = table.evaluateXPath(".//TR/TD[@class='surname']")
  results.snapshotLength
end

proc numberOfRows {} {
    set table [waitForObject \
        ":DOCUMENT.HTML1.BODY1.DIV1.DIV1.FORM1.TABLE1"]
    set results [invoke $table evaluateXPath {.//TR/TD[@class='surname']}]
    return [property get $results snapshotLength]
}

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) 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 we get a reference to the <table> and evaluate an XPath query (see How to Use XPath (Section 13.3.2)). The query used here says find all <tr> tags under the given element (i.e., in the table), and find all the <td> tags in the <tr> tags which have a class property with value “surname”. This produces an HTML_XPathResult Class (Section 14.10.35) object containing all the matching <td>s. Since each address has a single surname we know that the number of <td> tags with class “surname” is equal to the number of rows, so we simply return the number of items in the result using its HTML_XPathResult.snapshotLength property.

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

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