In addition to tools for recording and editing tests, Squish also provides support for debugging test scripts and for inspecting the AUT's internal objects. The debugger is not only useful for finding and fixing bugs in test scripts, but also—using its breakpoint facility—for inspecting a running AUT.
The Squish IDE's script debugger allows us to set breakpoints in our test scripts (see Debug view (Section 16.2.5)). This can be useful for when we want to insert verification points (see Inserting Additional Verification Points (Section 4.4)), or for recording from a breakpoint onwards, as discussed later in this section. Once a test script has stopped at a breakpoint we can continue test execution normally by clicking the toolbar button (or by pressing F8; Resume action (Section 126.96.36.199)), or we can step through the test script by clicking | (or by pressing F5; Step Into action (Section 188.8.131.52)) or by clicking | (or by pressing F6; Step Over action (Section 184.108.40.206)). Alternatively, we can simply stop the test execution by clicking the toolbar button (Ctrl+F2; Terminate action (Section 220.127.116.11)).
While at a breakpoint it is possible to use Squish's debugger to see the call stack and to use the Squish Spy to examine application objects' property values and to insert verification points.
In some cases it is useful to extend an existing test case with further actions. But it would be tedious to have to re-record the entire test from scratch just, for example, to click an additional button in the test. One solution it to simply edit the test script and add in a few lines with the additional actions that are required. But sometimes it is more convenient to simply record the extra actions at the point in the script where they are required.
Recording just a part of what is needed can also be useful in other contexts. One common use case is if we know that every one of a whole group of tests must always start out the same way by performing some initializing actions on the AUT—for example, opening a file of test data. We could easily just record these actions and then store them in a shared script. Then, for each new test case, we could write in the one line necessary to load in a shared script (see How to Store and Locate Shared Scripts and Shared Data Files (Section 13.21.1))—or we could create the test from a template with the line already in place (see Testcase Templates (Section 15.12))—and then record the text from that point onwards.
Recording within an existing test is made possible by setting a breakpoint in an existing test script at the point where the newly recorded actions should be inserted. Once the breakpoint is in place, execute the test—it will stop executing as soon as the breakpoint is reached. Now click | (Record Snippet action (Section 18.104.22.168)). This will make Squish start recording on the running AUT. Interact with the AUT to perform the new actions, and once you have finished, click Squish's controlbar window's button (Stop Recording action (Section 22.214.171.124)) to stop the recording. Now click the toolbar button (or press F8) or the toolbar button (Ctrl+F2). Once the script has finished or been stopped the newly recorded actions will be inserted into the test script at the breakpoint. At this point the entire script can be run again, this time including the newly recorded actions.
In the tutorials we saw how to insert verification points by using the Squish Spy. (See, for example, Inserting Additional Verification Points (Section 4.4) in Tutorial: Starting to Test Qt Applications (Chapter 4); or look in the equivalent section of the tutorial relevant to the GUI toolkit you're using.) Two approaches can be used: we can record a test script and then insert breakpoints into it—then run the test and add verifications at each breakpoint. Or we can record a test script and add verifications as we go along using the Insert Object Properties Verification Point action (Section 126.96.36.199) and Insert Screenshot Verification Point action (Section 188.8.131.52) both of which are available from the Control Bar Window (Section 16.1.3).
In either case, when a breakpoint is reached or a verification insertion is attempted, Squish will switch to the Squish Spy Perspective (Section 184.108.40.206) so that application objects and their properties can be inspected and verification points inserted as required.
It is also possible to use the Spy independently (except for the
Squish for Web edition). Simply click the toolbar button; this will start the AUT and switch
Squish to the Squish Spy Perspective (Section 220.127.116.11). Interact
with the AUT however you like, and at any point you can see the current
Application Objects in the Application Objects view (Section 16.2.1) and the currently selected
Object's Properties in the Properties view (Section 16.2.11).
(Note that to use the Spy with Squish for Web, you must have a test
script which opens a URL. Set a breakpoint after the
loadUrl call, and execute the test script. When
the test script stops at the breakpoint, you can then use the Spy.)
Those Objects in the Application Objects view (Section 16.2.1) that have child objects can be expanded to reveal these objects (and so on, recursively). There is also a context menu that offers options for copying the current object's symbolic or real (multi-property) name to the clipboard: this is useful if you want to refer to the object in a test script that you are writing or editing. (In general it is best to use the symbolic name.) If you do this, be sure to invoke the context menu a second time and choose the option so that Squish will remember the object and recognize it when you use it in your test cases.
There is also a view that shows each Object's methods (Methods view (Section 16.2.8)). In general, any of these methods can be used in test scripts, for example to test that a particular widget has the expected state.
The Spy is especially useful when writing test scripts by hand since it can be used to find out the names of the AUT's objects and which of their properties are accessible and what methods they provide.
|Quickly Populating the Object Map|
A fast alternative to using the Spy tool when you want to find out the names of lots of objects, is to create a dummy test. During this test you must interact with all the objects you want to use in your test script—this will make Squish add entries for all the objects to the Object Map (Section 15.9) all in one go. You can then copy and paste the names—preferably the symbolic ones—into your test script as needed, and then delete the dummy test.
When you start spying on an AUT, at first the main window (or first web page) is shown in the Application Objects view (Section 16.2.1) along with all its child objects. If you then pop up a dialog, neither the dialog nor its child objects are shown in the Application Objects view (Section 16.2.1). This is easily remedied by clicking the Application Objects view (Section 16.2.1)'s toolbar button. (You can also do a refresh after the dialog has been closed to remove the dialog objects that are shown in the Application Objects view (Section 16.2.1).)
The Spy (Squish Spy Perspective (Section 18.104.22.168)) has two modes of operation: Normal (which is the default) and Pick. The Normal mode is almost always sufficient (along with the use of the Application Objects view (Section 16.2.1)'s toolbar button). However, Squish also provides the Pick mode which makes it possible to view one particular object in the Application Objects view (Section 16.2.1).
Before entering Pick mode, interact with the AUT to make the object you are interested in visible. Then click the Application Objects view (Section 16.2.1)'s toolbar button. This will switch Squish into pick mode—Squish's main window will disappear and instead the Control Bar Window (Section 16.1.3) will be shown. Now click the AUT's active window to give the AUT the focus. As you move the mouse over the window each object (i.e., widget) will be highlighted by being outlined in red. In addition, Squish will show the highlighted object's real name in a tooltip.
Once the object you are interested in is highlighted click (or double-click depending on your platform and settings) it to pick it—this will also return the Spy to its Normal mode. Now the object will be shown as the sole entry in the Application Objects view (Section 16.2.1) with its properties shown in the Properties view (Section 16.2.11). As usual you can copy its name to the clipboard and add it to the Object Map (Section 15.9) using the context menu.
To finish spying, click the Squish stop the AUT and return to the Squish Test Management Perspective (Section 22.214.171.124).toolbar button. This will make