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. This can be useful for when we want to insert verification points (see Inserting Verification Points (Section 5.3)), or for recording from a breakpoint onwards, as discussed later in this chapter. Once a test script has stopped at a breakpoint we can continue test execution normally by clicking |, or we can step through the test script by clicking | or |.
To stop a test run without setting a breakpoint, click |. And to continue a test run that has been stopped, simply click | once again.
Sometimes during test execution it is useful to track the line that is currently being executed. The Squish IDE has a facility for doing this—click |, then click the tab, and finally, click the checkbox.
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 15.4.1))—or we could create the test from a template with the line already in place (see Testcase Templates (Section 16.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. At this point, click, | which starts recording on the running AUT. Now, interact with the AUT to perform the new actions, and at the end click Squish's |. This will stop the recording and the newly recorded actions will be inserted into the test script at the breakpoint.
One way of extending an existing test is to record additional actions at a breakpoint. (This is explained in How to Record After a Breakpoint (Section 15.2.2).) But if we have a very long test script with lots of time consuming actions and want to record something near the end, we can often take an alternative approach.
Squish has a facility whereby we can run the AUT and then, at a time of our choosing, we can tell Squish to start recording and to insert the recorded actions at the cursor position in the current script. This is done by right-clicking in the test script and choosing the context menu item, . This will cause Squish to start the AUT and open the Squish control bar. You can then work with the AUT as if Squish wasn't running and when you want to start recording, simply click the toolbutton in the Squish control bar (this toolbutton has the same icon as the normal record button in the Squish IDE). When you've finished recording your actions simply hit the stop button in Squish's control bar and Squish will insert the newly recorded code at the position where your cursor was.
In How to Create and Use Verification Points (Section 15.3) and Inserting Verification Points (Section 5.3) in the tutorial Tutorial: Starting to Test Qt Applications (Chapter 5), we used the Spy to insert verification points.
The Spy can be used independently, that is, without a test script (except for the Squish/Web edition), to inspect the application, its objects, and their properties.
To use the Spy with Squish/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.
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.
![[Note]](images/note.png) | Note |
|---|---|
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 16.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. |
To start the Spy, click the toolbar button (or | menu option). This will cause Squish to start the currently active test suite's AUT and to switch to the Squish Spy Perspective. (Note that for Squish/Web, you must choose the menu option after starting the test script, once the breakpoint has been reached and the AUT stopped.)
The Spy has three different modes:
Run mode—The Spy is active and you can navigate in the object and property hierarchy views. In this mode all user events to the AUT are blocked, so interacting with the AUT is not possible.
Pause mode—The Spy is inactive and all events to the AUT are processed normally, so you can interact with the AUT as normal. You usually switch to this mode when you want to get the AUT into a particular state or open a particular dialog before starting to spy. The procedure is to start the Spy, then pause it, then get the AUT to the state or dialog you want to spy on, and then start (run) the Spy again. This will allow you to navigate in the object hierarchy and property hierarchy of the AUT in its current state, or of the AUT dialog that you opened.
Pick Object mode—The Spy switches the AUT into object picking mode. In this mode you can choose a widget in the AUT by moving the mouse to the widget you are interested in and clicking it. If you chose one of the AUT's widgets in this mode, its object hierarchy and properties will be displayed in the Spy's views.
To finish spying, click | again—this works because it is a toggle action.
When the Spy is first started it enters the Run state. If you want to find out the name of a widget in the AUT, switch to the Pick Object state by clicking |. Now context switch to the AUT (which Squish has already started). When moving the mouse over the AUT's widgets, the widget that would be chosen if the mouse were clicked is shown with a red frame around it, and if the mouse is hovered a tooltip showing the name and type of the widget will appear. Once the widget you want is framed, click it to choose it.
Once a widget has been chosen in Pick Object mode,
the Spy will automatically switch back to Run
mode and display the chosen object, along with its children and
properties in the Spy views. The objects have a context menu, so by
right clicking on the object in the Spy view, you can copy the name to
the clipboard and paste it into the test script where needed (e.g. for a
waitForObject() call) or you can add the
object directly to the object map. See also Editing an Object Map (Section 16.9.2.2).