The Application Objects view is shown in the Squish Spy Perspective (Section 8.1.2.1) and the Squish Test Debugging Perspective (Section 8.1.2.3). it shows all the application objects that the Squish IDE currently knows about and presents them in a tree hierarchy.

The Application Objects view

The currently selected object's properties are shown in the Properties view (Section 8.2.12). The tree of objects is lazily populated to improve performance. This means that if you expand an item that has lots of child items (e.g., a tree, table, or list widget), it might take a moment or two before those items become visible.

If you interact with the AUT after the Application Objects view has been shown—for example opening an AUT dialog—the new application objects may not be visible in the Application Objects view. This can easily be solved by clicking the view's Refresh toolbar button ().

The view's Show Parent toolbar button () allows you to retrieve the parent object of the currently selected one. There are different valid reasons why picking () an object doesn't hit the desired one. Being able to walk the object hierarchy upwards then, helps in getting to the correct object in the Application Objects View.

If you want to find an object visually without drilling through the object tree, interact with the AUT as necessary to make the widget visibile, then click the view's Pick toolbar button (). Next click the AUT to give it focus and now as you move the mouse over the AUT's widgets, the widget under the mouse is shown outlined in red, and a tooltip shows the widget's real (multi-property) name. Click the widget you are interested in: this will result in the Application Objects view showing just that widget—and of course the Properties view (Section 8.2.12) will show the widget's properties. (If you want to see all the application objects again simply click the view's Refresh toolbar button ().

The view's Highlight Object toolbar button () lets you enable the highlighting of the objects inside the AUT. So when clicking an object in the Application Objects View with Highlight Object being activated, Squish highlights the corresponding object in the AUT. Note, that Squish is not trying to set focus to the AUT or bringing it to the foreground, so you might have to rearrange windows to correctly see the highlighting. The button's toggle behavior means you only have to enable the highlighting once, and then get the highlighting shown for any object that is clicked in the Application Objects View.

The Application Objects view provides a context menu with four options: Copy Real Name, Copy Symbolic Name, Add to Object Map and Save Object Snapshot.... The first two menu options are useful when you want to edit a test script and insert an object's name into it. (It is usually more convenient to use the symbolic name in such cases.) If you do intend copying an object name to the clipboard and pasting it into a test script, make sure that you add the name to the object map using the Add to Object Map menu option so that Squish will remember it when the test is run.

The fourth option, Save Object Snapshot..., opens a dialog which allows creating a snapshot of the object hierarchy beneath the selected object in the Application Objects view. The snapshot includes all objects, their properties and optionally a screenshot of each object and the object names. On the hard disk, the snapshot is just an XML file which represents the object hierarchy.

Object snapshots can be very useful for debugging problems. The snapshots can be shown in a dedicated browser program which shows the object hierarchy as well as any other contained information.

(See also, How to Use the Spy (Section 5.21.3).)

The Breakpoints view is not shown in any perspective by default. It can be shown by using the Show View action (Section 8.1.1.62) or by pressing Shift+Alt+Q, B. It shows a list of the currently set breakpoints.

The Breakpoints view

The checkbox beside each breakpoint is checked for those that are enabled and unchecked for those that are disabled. You can check and uncheck them at will. Disabled (unchecked) breakpoints are not stopped at. (It is also possible to enable and disable breakpoints inside an Editor view (Section 8.2.6) using a context menu.)

The Breakpoints view provides several toolbar buttons—the following table briefly describes the actions they perform.

Icon	Toolbar Button Name	Action
	Remove Selected Breakpoints	Removes the selected breakpoints.
	Remove All Breakpoints	Removes all the breakpoints—this can also be done by invoking the Remove All Breakpoints action (Section 8.1.1.51).
	Show Breakpoints for Selected Target	This toolbar button is inherited from Eclipse; it is not functional in the Squish IDE.
	Go to File for Breakpoint	Makes the Squish IDE open an Editor view (Section 8.2.6) showing the file that contains the selected breakpoint if it isn't already open—and if it is open, it is made active—and puts the cursor on the line containing the breakpoint.
	Skip All Breakpoints	A toggle button. If down, all breakpoints are skipped. (For finer control, disable those you want skipped.) (Skipping breakpoints is not supported in Squish IDE versions 4.0.0 and 4.0.1.)
	Expand All	Expands all the entries shown in the view if they are being shown as a tree rather than as a list.
	Collapse All	Collapses all the entries shown in the view if they are being shown as a tree rather than as a list.
	Link with Debug View	This toolbar button is inherited from Eclipse; it is not functional in the Squish IDE.
	View Menu	This menu provides menu options for controlling various breakpoint-related aspects—for example, a Group By menu option that can be used to specify how the breakpoints are grouped in the view.

The Squish Script Console in the Console view is shown in the Squish Test Debugging Perspective (Section 8.1.2.3). It can be used to interact with AUT objects, to perform computations in the scripting language being used for the AUT's tests, and to make additions to the test log. This view is also sometimes used to track down object not found or object not ready errors.

The Console view (left) and the updated Test Results (right)

The Squish Script Console basically lets you do everything that can be done in the test script itself, except that accessing test script variables may not be available in every script language, and changing test script variables is not supported.

Much like Unix shell, Squish Script Console remembers commands that were entered and stores them in history file so that they can be edited or executed again later. History is remembered across debugging sessions as well as IDE restarts. To scroll through previously executed commands, the following keyboard shortcuts are available:

The Call Hierarchy view is not shown in any perspective by default. It can be opened by invoking the Call Hierarchy action (by pressing Ctrl+Alt+H; see the Editor view (Section 8.2.6)'s Text Area Context Menu table for details), or chosen by using the Show View action (Section 8.1.1.62). The Call Hierarchy view shows the functions called from the selected function or the functions called by the selected function. (In this case, selected means that the function's name must be selected in an Editor view (Section 8.2.6).)

The Call Hierarchy view

(Note that this view is not functional for all scripting languages.) By default the Call Hierarchy view shows the functions called by the selected function as a tree. So if you are in the main function you will see the entire hierarchy of calls. If you select a particular function the line number where it is called is shown in the right hand pane.

The view has a few toolbar buttons of which the most useful are the Callees toolbar button () and the Callers toolbar button (). Both the buttons are toggle buttons only one of which can be toggled at any one time. If the Callees toolbar button () is toggled the view shows all the functions called by the selected function. And if the Callers toolbar button () is toggled the view shows all the functions that call the selected function. If you click on a function in the tree the view's right hand pane will show the line where the function is called and an Editor view (Section 8.2.6) will be activated (or opened) showing the relevant file and highlighting the call.

The Debug view is shown in the Squish Test Debugging Perspective (Section 8.1.2.3). It shows the filename and line number where Squish has stopped—for example, at a breakpoint—including a full backtrace.

The Debug view

It is possible to jump to anywhere in the backtrace, simply by clicking the relevant item in the tree. The Debug view provides several toolbar buttons—the following table briefly describes the actions they perform.

Icon	Toolbar Button Name	Action
	Remove Terminated Launches	Clears the details of any AUTs that have been terminated from the view
	Resume	Invokes the Resume action (Section 8.1.1.54).
	Suspend	Invokes the Suspend action (Section 8.1.1.73)—this action is not needed or functional in the Squish IDE.
	Terminate	Invokes the Terminate action (Section 8.1.1.75).
	Disconnect	This action is not functional in the Squish IDE.
	Step Into	Invokes the Step Into action (Section 8.1.1.70).
	Step Over	Invokes the Step Over action (Section 8.1.1.71).
	Step Return	Invokes the Step Return action (Section 8.1.1.72).
	Drop To Frame	This action is not functional in the Squish IDE.
	Use Step Filters	This toggle action is not functional in the Squish IDE.
	View Menu	This menu provides menu options for controlling how the view presents its data.

The Editor view provides tabbed editors for viewing and editing a test suite's test case's test scripts. It is shown in all perspectives.

The Editor view

The Editor view's editors show line numbers and color syntax highlighting appropriate for the scripting language being used. In addition each editor is language-savvy and provides automatic indentation and other language-specific convenience features. These features are controlled though the Pref­er­ences dialog (Section 8.3.17)—each supported scripting language has its own entry in the Preferences dialog's left-hand list, and within each language entry there is an Editor entry through which editing preferences can be set. In addition, general editing settings—that apply to every scripting language unless overridden—can be set in the Preferences dialog's General item's Editors subitem's Text Editors subsubitem (and its subsubsubitems). Note that if you hover the mouse over an Editor view tab the full path to the view's file is shown.

Every editor has two context menus, one that is invoked in relation to the line numbers and another that is invoked in relation to the editor's text area. The first is the same for all editors; the second has variations depending on the scripting language being used. The menu options offered by these context menus are shown in the following tables.

Table 8.1. Line Number Context Menu

Context Menu Option Name	Action
Toggle Breakpoint	Invokes the Toggle Breakpoint action (Section 8.1.1.77).
Disable Breakpoint	Disables the breakpoint at the current line if there is one and it is enabled.
Record Snippet	Invokes the Re­cord Snip­pet action (Section 8.1.1.46)
Replace With TestData Field	This context menu option is currently not functional in the Squish IDE.
Show Quick Diff	This context menu option is currently not functional in the Squish IDE.
Show Line Numbers	This menu option is checkable—if checked the editor shows line numbers; otherwise it doesn't.
Folding	This menu option has a submenu with options shown in Table 8.2, “Folding Context Menu”. Folding is where instead of showing the entire test script only the first line of each function or block or comment is shown. This makes it easier to see a script's overall structure. You can expand or collapse individual function entries by clicking the or icons shown beside the line number; or expand or collapse everything using the submenu options listed above.
Preferences	Invoking this option pops up the Pref­er­ences dialog (Section 8.3.17) at the editor preferences item for the scripting language being used.
Breakpoint Properties	This item is only enabled if the current line has a breakpoint, in which case it pops up a Properties dialog that can be used to make the breakpoint more sophisticated rather than always stopping the script unconditionally.

Table 8.3. Text Area Context Menu

Languages	Context Menu Option Name	Action
JavaScript, Perl, Python, Ruby, Tcl	Undo	Invokes the Undo action (Section 8.1.1.81).
JavaScript, Perl, Python, Ruby, Tcl	Revert File	This menu option restores the editor's contents to what it had when it was last saved. (The same effect can be achieved somewhat less conveniently by repeatedly invoking the Undo action (Section 8.1.1.81).)
JavaScript, Perl, Python, Ruby, Tcl	Save	Invokes the Save action (Section 8.1.1.56).
JavaScript, Perl, Python, Ruby, Tcl	Open Declaration	This menu option (invoked by F2) is not functional in the Squish IDE.
JavaScript, Python, Tcl	Open Type Hierarchy	This menu option (also invokable by pressing F4) shows the class hierarchy (super- and sub-classes) of the class of the item under the cursor. (Note that this is only functional for those scripting languages and classes for which the Squish IDE has the appropriate information.)
JavaScript, Tcl	Open Call Hierarchy	This menu option (also invokable by pressing Ctrl+Alt+H) opens the Call Hierarchy view (Section 8.2.4) view. This view shows a tree of the current function and the functions it calls. If invoked in the test script's main function it shows the entire hierarchy of functions that the test script calls. If you choose a called function anywhere in the hierarchy the view also shows the line number(s) where the function is called.
JavaScript, Python, Tcl	Quick Outline	This menu option (also invokable by pressing Ctrl+O) pops up a dialog showing the file's structure—for example, its functions and global variables. If you navigate using the up and down arrow keys and press Enter on an item the dialog will close and the editor will show the item you chose; or just press Esc to cancel. (Note that this is only functional for those scripting languages for which the Squish IDE has the appropriate information.)
JavaScript, Python, Tcl	Quick Type Hierarchy	This menu option (also invokable by pressing Ctrl+T) shows a tree of the current function and the functions it calls. It is similar to the Open Type Hierarchy option, but uses a dialog rather than a view to present the information.
JavaScript, Perl, Python, Ruby, Tcl	Show in	This menu option (also invokable by pressing Shift+Alt+W) is not functional in the Squish IDE.
JavaScript, Perl, Python, Ruby, Tcl	Cut	Invokes the Cut action (Section 8.1.1.12)
JavaScript, Perl, Python, Ruby, Tcl	Copy	Invokes the Copy action (Section 8.1.1.10)
JavaScript, Perl, Python, Ruby, Tcl	Paste	Invokes the Paste action (Section 8.1.1.36)
Perl	Shift Right	Moves the current line right two spaces.
Perl	Shift Left	Moves the current line left two spaces (if possible).
JavaScript, Perl, Python, Ruby, Tcl	Source	This menu option has a submenu with options shown in Table 8.4, “Source Submenu”. Note that when an editor view is active there is also a Source menu available from the menu bar. This menu has the same (or in some cases fewer) menu options as the context menu described here.
Perl	Refactor	This menu option has a single submenu option Extract Subroutine that functions only if some lines are selected. If you invoke Extract Subroutine, first it prompts you for a subroutine name, then it creates a subroutine with the given name that contains the selected lines, and finally it replaces the original lines with a call to the subroutine.
Perl	Perldoc	This menu option (also invokable by pressing Shift+Ctrl+H) is intended to run perldoc but is not functional in the Squish IDE.
JavaScript, Python, Tcl	Search	This menu option is not functional in the Squish IDE; however, the menubar Search action (Section 8.1.1.59) provides search facilities
JavaScript	Paste to JavaScript Console	This menu option is not fully functional in the Squish IDE—all it currently does is copy the selected text to the clipboard
Tcl	Paste to TclConsole	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, Tcl	Run As	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, Tcl	Debug As	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, Tcl	Team	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, Tcl	Compare With	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, Tcl	Replace With	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, Tcl	Record Snippet	Invokes the Re­cord Snip­pet action (Section 8.1.1.46)
JavaScript, Perl, Python, Ruby, Tcl	Make Code Data Driven	This menu option inserts a loop that accesses every field in a test data file—it is only available if there is a test data file available to the test script. Make sure the cursor is on an empty line where you want the code to be inserted. Then choose this menu option and a Refactoring wizard will appear. The Refactoring wizard lists the test data file or files that are available: click the one you want to use, then click the Next button. The wizard will now show you the test script's current code and the code you'll have if you finish, as the screenshot shows: Click the Finish button to have the code inserted. (You can always use the Undo action (Section 8.1.1.81) if you change your mind.)
JavaScript, Perl, Python, Ruby, Tcl	Replace With TestData Field	This menu option inserts a call to the testData.field function to access a data item from a record in a test data file—it is only available if there is a test data file available to the test script. Make sure the cursor is where you want the code to be inserted—for example to the right of an assignment such as averagingTime = . Then choose this menu option and pick a submenu option—these options correspond to the fields that are available in the current test data—and a Refactoring wizard will appear. The Refactoring wizard will now show you the test script's current code and the code you'll have if you finish. Click the Finish button to have the code inserted. (You can always use the Undo action (Section 8.1.1.81) if you change your mind.) So if we started with averagingTime = , our code will now be averagingTime = testData.field(record, "Averaging Time"). Note that in general it may be more convenient to use the Make Code Data Driven menu option and then copy and paste any testData.field function calls that you need.
JavaScript, Perl, Python, Ruby, Tcl	Preferences	Pops up the Pref­er­ences dialog (Section 8.3.17) showing the preferences for the current editor view's type (e.g., Python editor, Tcl editor, etc.)
JavaScript, Perl, Python, Ruby, Tcl	Input Methods	This menu option leads to a submenu of input method submenu options. These are useful for test engineers who are using non-Latin languages (e.g., those not using English or West European languages) and who wish to enter text in their own language

The Global Scripts view is shown in the Squish Test Management Perspective (Section 8.1.2.2). It shows the global scripts folders and the scripts they contain. These scripts can be accessed by any test case in any test suite. The view provides a means of adding and removing global scripts and global script folders. By default the view is shown beside the Editor view (Section 8.2.6), but it can easily be dragged elsewhere if that's more convenient—for example, to be another tab beside the Test Summary view (Section 8.2.20).

	Advanced
	Global scripts are an advanced feature. They are not recommended for new Squish users. Even experienced users should use them with care—changing or deleting functionality (and in some cases even adding functionality) to a global script will affect every test case in every test suite that uses the global script. If you plan to use global scripts we recommend putting them under version control.

The Global Scripts view

The first time the view appears all its toolbar buttons are disabled because no global scripts folders yet exist. Invoke the view's context menu (e.g., on most platforms by right-clicking the view), and choose the Add|Global Script Directory option. Use the folder dialog that pops up to choose or create a folder where global scripts will be stored. (There is no limit to the number of such folders that you can create.)

Once at least one folder exists you can create globally shared script files using the context menu's Add|File option or using the New Scriptfile toolbar button. New script files are called script_1.py and so on (with the appropriate scripting language extension of course). They can be renamed immediately by entering a new name, or at any time later by using the context menu's Rename option. Simply click the filename to invoke an Editor view (Section 8.2.6) in which to edit the file. Script files can easily be deleted by clicking their name in the view and using the context menu's Delete option or the Delete toolbar button—but great care must be taken since these scripts may be being used by many test cases in many test suites.

Global scripts are accessed using the same technique as we use for local scripts. For example, given a global script called global.py (or similar), we can make its contents available to the test case script in the usual way:

source(findFile("scripts", "global.py"));

This statement, uses the findFile function to get the script's full name including its path and the source function to evaluate the script to make its classes, functions, and variables accessible to the test case script.

The Image view is shown in the Squish Test Management Perspective (Section 8.1.2.2). It displays images opened either from the Test Suites view (Section 8.2.19) or from the Test Results view (Section 8.2.18) (for example failed images).

The Image view, highlighting the zoom buttons

The Image view provides a couple of actions for zooming the image in the main toolbar of the IDE, in this order: a zoom-in button, a button to set the zoom factor to 100%, a zoom out button and finally a button that makes the image fit the window. The view is intended to fill a gap on systems where the IDE does not have access to the platforms standard image viewer and only provides basic viewing capabilities of the image.

It is possible to adjust the IDE's configuration to use a different viewer for images opened through the Test Results view (Section 8.2.18) or the Test Suites view (Section 8.2.19). This is done through the File Assoications page in the Pref­er­ences dialog (Section 8.3.17). File Associations are stored on a file type basis, so for each image file type (png, gif, jpg) there's a separate entry. Selecting that entry fills the lower list of Associated Editors with entries that the IDE knows for opening such files. Clicking the Add... button for the Associated Editors list opens a dialog. Selecting External Editor here allows selecting any program installed on the system for opening files of the given file type. This change offers these additional editors in the Open With context menu.

In order to have image files opened from the Test Results view (Section 8.2.18) use that editor the default editor for that file type needs to be changed. This can be done by selecting the corresponding editor entry and clicking on the Default button next to the list.

The Methods view is shown in the Squish Spy Perspective (Section 8.1.2.1) and the Squish Test Debugging Perspective (Section 8.1.2.3). It shows the methods that can be called by the object highlighted in the Application Objects view (Section 8.2.1)—or by any other AUT object that has the same type.

The Methods view

The methods are shown using their native syntax (e.g., C++ in the screenshot above), so a tiny bit of mental translation may be needed to do the call you want.

The view allows filtering the list of methods based on some part of the method name, for example searching for the text round will reduce the part of the list visible in the screenshot above to the two methods containing this text in their name. The filter works case-insensitive and also allows simple wildcard matching.

The view has a context menu that supports the Select All action (Section 8.1.1.60) and the Copy action (Section 8.1.1.10).

The Object Map view is not shown in any perspective by default. It can be shown by clicking the Test Suites view (Section 8.2.19)'s Object Map () toolbar button. Another way to see it is to right-click on a symbolic name in one its test cases, and select Open Symbolic Name. The Object Map view can be used to rename, add, edit, and delete entries from the test suite's object map. It can be used with the Text Based as well as Script-Based Object Maps.

The Object Map view

Storage of Object Names

There are 2 ways that the Object Map can be stored. For Script-Based Object Maps, we use names.<ext> under the shared/scripts directory of the test suite. For Text-Based Object Maps, it is stored a file called objects.map, which is plain text, in the test suite's root directory. In either case, you can the Object Map view, a script editor, a plain text editor, or a code editor in squishide for editing object map entries.

The Object Map view is split into an upper and a lower panel. The upper panel is labeled “Symbolic Names” and shows the AUT's symbolic names—these are the names Squish uses when it records test scripts. These names are shown in a hierarchy, so if you don't see the name that you are interested in you may have to expand one or more entries to find it. It is best to use symbolic names wherever possible since they make it easier to adapt to changes in the AUT without being forced to change the test scripts themselves. The lower panel is labeled “Real Name” and shows the "value", which is usually a set of properties associated with the highlighted symbolic name.

In the screenshot, the highlighted symbolic name is address_Book_MyAddresses_adr_File_QTableWidget. By looking at its properties, we can see its real (multi-property) name: {"aboveWidget": address_Book_MyAddresses_adr_File_QToolBar, "type": "QTableWidget", "unnamed": 1, "visible": 1, "window": address_Book_MyAddresses_adr_MainWindow}. If later on, the AUT's developers decided to use a QTableWidget subclass, say, EnhancedTableWidget, all our test scripts that used the widget would break. Thanks to the Object Map, we don't have to edit any of our scripts to fix this; instead we can simply change the type property's value to the new class name and all our scripts will work again. The flexibility and power of Squish's Object Map is one of the reasons why Squish tests are so robust in the face of AUT changes.

No Undo

The Object Map view does not have an undo facility. In view of this, if you plan to delete or edit entries, we recommend making a backup of the test suite's objects.map file before making any changes. If you do make a mistake—for example, delete a symbolic name by accident—the easiest solution is to click the view's close button (X) and then click the No button when prompted to save changes to the Object Map. This will revert all the changes you've made.

The most common operation is renaming an entry. If you double-click on a symbolic name, you can edit it. After you save changes (provided you are using the Script-Based Object Map), a refactoring operation will happen, and the variable will be renamed in all test cases of your test suite.

Another common operation is to edit an entry's properties. For example, you might have an object with a windowTitle property whose value is Address Book - Untitled, but it changes over time. Squish will detect this and create a new symbolic name for each value, but if you want to use one symbolic name for all values, you could make the entry more general by removing or editing its windowTitle property. By setting the operator to Wildcard and the value to Address Book*, this will match the window title when other files are opened later. (For more about matching object names see Improving Object Identification (Section 7.10).)

The Object Map view's upper panel can be used to remove existing symbolic names by selecting the name and clicking the upper panel's Remove button. As noted, there is no undo facility, so this feature should be used with care.

It is also possible to create a completely new symbolic name. To do this, click the upper panel's New button. This will create a new symbolic name with a default name of "NewName" (or "NewName1" and so on if that name is already in use), and with no properties at all. Double-click the name to make it editable, and then change the name to something that makes sense for your test suite. You can then add new properties by clicking the lower panel's New button once for each new property you need. Each property's name and value can be set by double-clicking the relevant cell and typing in the appropriate text. The operator can also be set by double-clicking and then using the up and down arrows to select the operator you want. For most GUI toolkits (the exceptions being Squish for Windows and Squish for Web), every real name should have a type property, so be sure to add this property and set its value to the name of the object's type. Usually it is best to set at least two properties to help ensure that the object is uniquely identified.

It is possible to delete properties simply by selecting them and clicking the lower panel's Remove button. As noted, there is no undo facility, so this feature should be used with care.

These buttons are only enabled while the AUT is running. In cases where the AUT's GUI has changed, you might want to check whether the object a symbolic name refers to can be found. This can be done by selecting the name and clicking the Check Existence button. If it is not found, a red "x" appears. If it is found, a green check mark appears, and Highlight Object can be used to show it in your GUI with a transparent red rectangle over it.

The Object Map view has a context menu with some standard actions (specifically, the Copy action (Section 8.1.1.10), the Cut action (Section 8.1.1.12), the Paste action (Section 8.1.1.36), and the Delete action (Section 8.1.1.13)). The Copy action copies the selected symbolic name to the clipboard. If you want the real (multi-property) name, use the Copy Real Name option to copy the real name to the clipboard.

Some AUTs have lots of symbolic names. If you are looking for a specific object, you can type some part of its name into the Filter Object Names line edit. For example, if you wanted to find a particular button, enter the button's class name (e.g., Button) and the list of symbolic names will be narrowed down to all those which contain the text “Button”.

For information about handling the Object Map programmatically in test scripts, see Object Map Functions (Section 6.3.11). For more about Object Maps in use, see the Object Map (Section 7.11).

The Outline view is not shown in any perspective by default. It can be shown by using the Show View action (Section 8.1.1.62) or by pressing Shift+Alt+Q, O. It shows the active file's structure: its classes, and its functions and their variables.

The Outline view

By default the view shows the classes and functions declared in the active Editor view (Section 8.2.6). (Note that the display of variables is not supported for all scripting languages.) The view has a few toolbar buttons: one for sorting the contents alphabetically (i.e., sorting both the functions and the variables used by each function); and some toggle buttons to switch off or on the display of classes, functions, and variables.

The Properties view is shown in the Squish Spy Perspective (Section 8.1.2.1) and the Squish Test Debugging Perspective (Section 8.1.2.3). It shows the properties of the Application Objects view (Section 8.2.1)'s selected object. The name of the selected object is shown above the properties.

The Properties view

Multi-valued properties such as font and geometry have their value shown as a brace enclosed list of key = value pairs, although each individual value can be seen by expanding the property as the screenshot above shows for the frameGeometry property.

If a test is being recorded or played back (i.e., when the Squish Test Debugging Perspective (Section 8.1.2.3) is active), clicking a property will make the Verification Point Creator view (Section 8.2.22) become visible (if it isn't already), with the clicked property shown as a potential verification point. You can click as many properties as you like this way to create multiple verifications. (Note: Verification points are only actually inserted into the test script if you click the Verification Point Creator view (Section 8.2.22)'s Insert button.)

(See also, How to Use the Spy (Section 5.21.3).)

The view allows filtering the list of properties based on property name, for example entering the text frame will show in the list, only the two properties containing frame in their name. The filter is case-insensitive and also allows simple wildcard matching.

The Runner/Server Log view is initially docked at the bottom when in any perspective. If hidden, it can be shown by using the Show View action (Section 8.1.1.62). It logs messages from both the squishrunner and squishserver. When things are not working correctly, it often shows relevant error messages related to AUT launching and hooking, timeouts, etc.

The Runner/Server Log view

Log lines beginning with S: are from the squishserver and lines beginning with R: are from the squishrunner. Lines that don't start with either of these are from the Squish IDE.

The Log view has a context menu through which the log's contents can be selected and then copied to the clipboard and then pasted into, say, an email. For example, you might be asked to do this by froglogic to help solve a problem that you've encountered.

The Image Selection Editor view is shown when we choose to insert an image-based action function using a new image into the test script. The insertion is initiated via the Insert > mouseClick(<Image>) action (Section 8.1.3.8), Insert > doubleClick(<Image>) action (Section 8.1.3.9) or Insert > tapObject(<Image>) action (Section 8.1.3.10).

The Image Selection Editor view

The Image Selection Editor view allows you to mark a region of the desktop's screenshot, which will copy and store the region on disk for subsequent searches. You can use scrollbars to pan to different parts of the screen, and a slider or zoom buttons to zoom in and out of the image. Drag the default rectangular selection into the correct position, and resize the edges to make it fit the element to be searched. It's advisable to keep the amount of background pixels as small as possible for faster and more robust searches.

Before inserting, it is recommended to enter a meaningful file name into the Name. On insert, the selected image will be stored in the test suite's shared visual look-up directory (test_suite/shared/searchImages/) and used as an argument to the waitForImage function.

When clicking Insert <action> an attempt to execute the selected action will be performed, followed (upon sucess) by insertion of the respective script statement into the test script.

In case the first screen grab attempt returns an unwanted result, the Refresh and Refresh in 3 sec buttons come in handy for grabbing the screen again, either immediately or with a delay. The delay is meant to give the user a chance to arrange the application, for example by opening an application menu.

The Cancel button will abort the insertion of a new script statement and take us back to the main recording mode.

The Search view is not shown in any perspective by default. It can be shown by using the Show View action (Section 8.1.1.62); however, the usual way to make this view visible is simply to perform a search which uses this view to present its results.

The Search view

The screenshot above shows the Search view that appeared as the result of invoking the Workspace action (Section 8.1.1.84) (by pressing Ctrl+Alt+G) when the cursor was on a function called addNameAndAddress in an Editor view (Section 8.2.6) being used to edit a JavaScript test script. Here the Search view is showing the line where the search was initiated from (which is also where the function's definition begins), and the lines where the function is called or defined in other files in the same workspace (i.e., in the same test suite).

The Search view can appear as the result of a number of other search actions, some of which are scripting-language dependent.

The Search view provides several toolbar buttons—the following table briefly describes the actions they perform.

Icon	Toolbar Button Name	Action
	Show Next Match	Moves the highlight to the next match in the view and also makes the match visible in the Editor view (Section 8.2.6) (opening a new tab with a new file if necessary). This action can be invoked by pressing Ctrl+. (which when the Search view isn't active normally invokes the Next Annotation action (Section 8.1.1.29).)
	Show Previous Match	Moves the highlight to the previous match in the view and also makes the match visible in the Editor view (Section 8.2.6) (opening a new tab with a new file if necessary). This action can be invoked by pressing Ctrl+, (which when the Search view isn't active normally invokes the Prev­ious An­no­ta­tion action (Section 8.1.1.38).)
	Remove Selected Matches	Removes any selected matches from the view. This action can be invoked by pressing the Delete key
	Remove All Matches	Removes all the matches shown in the view
	Expand All	Expands all the matches shown in the view; this toolbar button is not available if viewing in list rather than tree format
	Collapse All	Collapse all the matches shown in the view so that only the root of the match tree is shown; this toolbar button is not available if viewing in list rather than tree format
	Run the Current Search Again	Reruns the search; this may be useful if files have changed since the search was last run
	Cancel Current Search	Cancels the current search; this is useful if the search is taking a long time—for example, because it is looking at a very large number of big files
	Show Previous Searches	If the non-menu part of the toolbar button is pressed a dialog is popped up showing a list of previous searches; if the menu part is pressed the list of previous searches is shown as a submenu
	Pin the Search View	If this toggle button is up (the default) any new searches show their results in the current Search view, displacing previous results (which are still accessible using the Show Previous Searches toolbar button). if this toggle button is down, this Search view is kept unchanged if a new search is performed and the new matches are shown in another Search view
	View Menu	This pops up a submenu of view options, including Show as List and Show as Tree (the default)

More or fewer toolbar buttons may be available depending on the context, for example, depending whether the view is showing the matches as a list or as a tree. There are also some toolbar toggle buttons (not listed above) that control how the matches are grouped.

The Test Suite Settings view is not shown in any perspective by default. It can be shown by clicking the Test Suites view (Section 8.2.19)'s Test Suite Settings toolbar button. It is used to view and edit test suite-specific information. (See also The suite.conf File (Section 7.4.3.2).)

8.2.16.1. Test Suite Information

The General tab (Test Suite Settings)

The Test Suite Information gets most of its values when the New Squish Test Suite wizard (Section 8.3.13) is used to create a new test suite: it cannot be changed.

The Description section can be used to give the test suite both a short summary and a longer description.

The Object Map specifies the name and path of the objects.map file. (If no path is given then Squish will look for it in the test suite's folder.) If you want to specify an objects.map file that isn't in the test suite's folder, you can either enter the filename and path directly or click the Browse button to pop up a file dialog to choose an objects.map file. If you enter a path by hand you can use an environment variable if you wish—for example:

$(TEST_ENVIRONMENT)\myapp\objects.map

If the environment in which the Squish tools execute has an entry of TEST_ENVIRONMENT = C:\TestFolder then Squish will read the Object Map from the C:\TestFolder\myapp\objects.map file.

The Object Map can be edited using the Object Map view (Section 8.2.10). For information about handling the Object Map programmatically in test scripts see Object Map Functions (Section 6.3.11). For more about Object Maps in use see the Object Map (Section 7.11).

8.2.16.2. AUT Information

The AUT is normally set to the name of the AUT's executable, although for Java AWT/Swing applications it is normally set to the main class (the class that contains the main method). For some AUTs it contains the name of a shell script or Windows .bat file. For Java™ applications it is possible to specify a CLASSPATH (although this is often done in a shell script or Windows .bat file for Java SWT applications). And for all application it is possible to specify the command line arguments that the AUT should be started with. If the Hook into sub-processes launched by the application checkbox is checked, Squish will also be able to test application's launched by the AUT—providing they use a GUI toolkit that Squish recognizes and is licensed for. (Java SWT applications must check this checkbox of course since the actual SWT application is launched from a shell script or Windows .bat file.) The Automatically start the AUT checkbox is unchecked by default and the AUT is started in the test script with a call to the startApplication function. This makes it possible to execute statements in the test script before the AUT is launched.

The AUT tab (Test Suite Settings)

The Working Directory is the folder where the AUT is run from. The default is the folder where the AUT's executable resides, but it is also possible to use the squishserver's working directory, or simply to choose any folder you like. If you choose the Custom location you can either enter a path or click the Browse button to pop up a file dialog to choose a path. If you enter a path by hand you can use an environment variable if you wish—for example:

$(TEST_ENVIRONMENT)\myapp

If the environment in which the Squish tools execute has an entry of TEST_ENVIRONMENT = C:\TestFolder then Squish will execute the AUT with the AUT's working directory set to the C:\TestFolder\myapp directory.

The Environment can be used to specify the environment variables (names and values) that should be present when the AUT runs. If you need an AUT-specific environment, simply click (or double-click depending on your platform and Squish IDE settings) an empty Key cell and enter an environment variable name. Then do the same to the corresponding Value cell. You can do this as many times as necessary. To delete a variable, simply delete its Key and press Enter. Note that Squish has two different environments: the environment that the Squish tools (such as squishserver and squishrunner) and the test cases execute in, and the AUT's environment. (See also, Setting Environment Variables (Section 7.3.3), Setting Environment Variables for the AUT (Section 7.3.3.1), and Environment Variables (Section 7.5).)

8.2.16.3. Connection Information

The Connection tab is only present for VNC test suites. It allows configuration of the connection parameters for the remote VNC server. For Protocol there are 2 choices, Native, which requires a squishserver to be running on the remote system, or VNC, where the actual VNC protocol is used to connect.

If Native is chosen, the actual host and port to use are specified in the Remote Testing Options.

If VNC is chosen, some additional fields are visible. Of those, all but Hostname are optional, and depend on the configuration of the VNC server.

The Connection tab (Test Suite Settings)

The password for the VNC server (if required) can be specified on the Password Information (Section 8.2.16.6) page. Once configured, it will become available as one of the options in the Password combo box.

8.2.16.4. Test Settings

The Test Settings tab contains a number of options that influence execution of all scripts in the test suite. The initial settings in this section get default values from the properties of testSettings Object (Section 6.3.19).

The Test Settings tab (Test Suite Settings)

The options available in the editor correspond to the following properties:

• waitForObject() timeout configures the default value for the testSettings.waitForObjectTimeout property;

• Log a screenshot on a PASS test result configures the default value for the testSettings.logScreenshotOnPass property;

• Log a screenshot on a FAIL test result configures the default value for the testSettings.logScreenshotOnFail property;

• Log a screenshot on an error configures the default value for the testSettings.logScreenshotOnError property;

• Verification Point retry timeout configures the default value for the testSettings.retryDuration property;

• Silent VP verifications configures the default value for the testSettings.silentVerifications property;

• Throw an exception on a test failure configures the default value for the testSettings.throwOnFailure property;

• Interrupt test execution on failure, as if breakpoint was set configures the default value for the testSettings.breakOnFailure property;

• Debug 'Object Not Found' interactively configures the default value for the testSettings.objectNotFoundDebugging property.

• Debug 'Image Not Found' interactively configures the default value for the testSettings.imageNotFoundDebugging property.

• Debug 'Text Not Found' interactively configures the default value for the testSettings.textNotFoundDebugging property.

8.2.16.5. Image Search

The Image Search tab contains options that influence squish image search functionality. The initial settings in this section get default values from the properties of testSettings Object (Section 6.3.19).

The Image Search tab (Test Suite Settings)

The options available in the editor correspond to the following properties:

• Tolerant image search configures the default value for the testSettings.imageSearchTolerant property;

• Image search threshold configures the default value for the testSettings.imageSearchThreshold property;

• Find resized images configures the default value for the testSettings.imageSearchMultiscale property;

• Minimal size configures the default value for the testSettings.imageSearchMinScale property;

• Maximal size configures the default value for the testSettings.imageSearchMaxScale property;

8.2.16.6. Password Information

The Passwords tab lets you associate a list of passwords with the current test suite. These passwords can be retrieved in the test script using the testSettings.getPassword function.

The Passwords tab (Test Suite Settings)

	Note
	The passwords stored in a Squish test suite have to be retrievable in plaintext form. Therefore, they are not stored in a "secure" way - they are just stored separately, so that it is not necessary to hard-code passwords in your test scripts.

8.2.16.7. Descriptions

The Descriptions tab (Test Suite Settings)

The Descriptions tab allows editing of a sort summary and a longer description for each of the test cases in the current test suite. It also allows specification of a comma-separated list of Tags for each of the script-based test cases. The Tags field for the BDD test cases is disabled, because the Gherkin file format allows assigning tags to a scenario in the file itself. Tagged test cases can be executed selectively as described in the Playback option --tags (Section 7.4.3.19) section.

This view is not shown in any perspective by default, but can be shown from any perspective by selecting Window-Show View-Other-Squish Tests-Squish Test Center.

The Test Center view

Initially, the view is empty. To see the available test results, a Squish Test Center must first be installed and running. Click the Configure Squish Test Centers button, and then click Add..., and enter the URL, email and password of your desired Squish Test Center server. You can check your inputs with Validate Settings before clicking OK to add the server.

Adding a Squish Test Center

Now, the table should be populated with rows representing batch runs (assuming some already have been uploaded to the Test Center previously). A row can be selected in the table and the Download tool button clicked, to bring the result into the Test Results view (Section 8.2.18).

The Test Center view, populated

The Test Results view is shown in the Squish Test Management Perspective (Section 8.1.2.2). It shows the results of the most recent test run.

The Test Results view

By default the view shows every kind of result: passes, fails, warnings, and so on. All these are controlled by the filter setting of the view using the corresponding toolbar dropdown and are on by default. Toggle any of them off if there are some categories that are not of interest.

The view has several toolbar items, starting with the Recent Results dropdown that allows loading test results that have been generated by an earlier test execution in the IDE. The following Next and Previous items in the toolbar jump backwards and forwards through the test results, stopping at each failure or error. The expand and collapse items following expand and collapse all nested entries in the results tree make it easy to go back to a highlevel view of the results after having drilled down. The View Differences toolbar item allows comparing the actual value of a verified object with the expected value stored in a verification point file. The Use as Expected item updates the verification point, replacing the current expected value with the actual one obtained during test execution. The Select New Image Search entry does a similar job for image lookups. The Jump to Video at Timestamp entry () opens up the Video Player view (Section 8.2.23) and automatically seeks the video to the timestamp of the currently selected entry in the test results. The Filter dropdown allows hiding certain types of results as explained above, and the Clear action empties the results view. The Export and Import tool items allow saving and loading test results in a zipped format that can be easily shared. Finally, the Upload Results to Test Center tool button allows uploading the results directly to Squish Test Center. This button will not be enabled unless a Squish Test Center is configured in the Test Center view (Section 8.2.17).

The view has a context menu that supports the Select All action (Section 8.1.1.60) and the Copy action (Section 8.1.1.10). There is also a Re-Run Test action which allows execution of the test case or scenario that the selected result entry belongs to. This makes it easy to re-run just the failed part of a larger test execution to investigate a failure. The other actions in the context menu are counterparts to the toolbar items explained above carrying the same names and icons.

The result entry location dialog

When using the import functionality to load test results generated on a different system, the Test Results view may not always find the paths and files mentioned in the report on the local system when you double click an entry to look at the test script. In such cases it'll use the above dialog to ask where the particular file or directory can be found on the local system. The Test Results view will then try to guess other paths it needs based on the selection, so that it does not have to ask for every single file.

The Test Suites view is shown in the Squish Test Management Perspective (Section 8.1.2.2) and the Squish Spy Perspective (Section 8.1.2.1). It shows the current test suite (in a combobox), a list of the suite's test cases, a list of the current test case's resources, and a list of the test suite's resources.

The Test Suites view

The test suite can be changed by interacting with the combobox. To the right of the combobox are some toolbar buttons. These are the New Test Suite toolbar button () which invokes the New Test Suite action (Section 8.1.1.28), the Open Test Suite toolbar button () which invokes the Open Test Suite action (Section 8.1.1.34), the Test Suite Settings toolbar button () which makes the Test Suite Settings view (Section 8.2.16) visible, and the Object Map () toolbar button which makes the Object Map view (Section 8.2.10) visible.

The Test Cases list also has toolbar buttons to its right. The first is the New Script Test Case () button which creates a new empty test case into which a new test script can be recorded, and the second is the Run Test Suite toolbar button () which runs every test case in the test suite one after the other. To run an individual test case on its own, click the Run Test Case toolbar button () to the right of the test case you want to run. To record a new test case click the Record Test Case toolbar button () to the right of the test case you want to record—be aware that if you use this on a non-empty test case the existing test script will be completely replaced! (You can always use the Undo action (Section 8.1.1.81) immediately after to fix this.) If you want to insert an extra recorded snippet into an existing test case use the Re­cord Snip­pet action (Section 8.1.1.46). To view or edit a test script in an Editor view (Section 8.2.6), simply click it (or double-click it, depending on your Squish IDE preferences).

The Test Case Resources and Test Suite Resources panels are structurally and functionally the same: the difference is that the former is concerned with test case specific resources and the latter with resources shared by the entire test suite. So we will describe them together as "Resources".

The Resources have two toolbar buttons to their right. The first is a New Test Script File toolbar button () which when clicked creates a new empty test script file, and the second is a New Test Data File toolbar button () which when clicked creates a new empty test data file. To view or edit a shared script or test data file simply click it (or double-click it, depending on your Squish IDE preferences) and a suitable editor view will appear.

To make use of a shared test script you must use the source function. And to access test data use the test data functions described in Test Data Functions (Section 6.3.10).

The Test Cases list and the Resources panels also have context menus with delete and rename options amongst others. If there is at least one test case present the Test Cases list's context menu has a Create Template from Testcase option. If this option is invoked it will pop up a Create Test Case Template dialog—simply enter the template's name and click the OK button to create a template that is an exact copy of the currently highlighted test case. The template is stored in the Test Case Template Directory; this directory can be changed in the Pref­er­ences dialog (Section 8.3.17)'s Squish pane's Test Creation child pane. To create a new test case based on the template, i.e., to create a new test case that's initially an exact copy of the template use the New dialog (Section 8.3.9)'s Squish Test Case from Template option. (See also Creating a New Template (Section 7.14.1).)

The Test Summary view is shown in the Squish Test Management Perspective (Section 8.1.2.2). It shows a summary of of the most recent test run's results.

The Test Summary view

The Test Summary view has a context menu with the Select All action (Section 8.1.1.60) and the Copy action (Section 8.1.1.10).

The Variables view is shown in the Squish Test Debugging Perspective (Section 8.1.2.3). It shows the test script's variables (which may include AUT objects), and their values.

The Variables view

The value of some objects is shown as <complex object>. This usually means that the object is a composite object, in which case we can expand it (since the Variables view is a tree view), to see the name, type, and value of each of its components. The view is kept up to date as you step through the program so you can watch variables come into existence, watch their values change, and finally watch them disappear when they go out of scope.

The view has a few toolbar buttons that affect various aspects of how and what data it displays. It also has a context menu with the Select All action (Section 8.1.1.60), a Copy Variables action (invokable by pressing Ctrl+C) that copies a variable's name, type and value— or its name, type and components' names, types, and values—to the clipboard, and a Find action (invokable by pressing Ctrl+F) that pops up a Find dialog for searching amongst the variables by their names.

The Verification Point Creator view appears automatically when we check a property's checkbox in the Properties view (Section 8.2.12) (unless it is already visible). This view is used to accumulate a list of one or more property verifications ready to be inserted into a test case's script.

The Verification Point Creator view

The verifications listed in the Verification Point Creator view are only inserted into the test script that is being recorded (or that is being played and is stopped at a breakpoint), if the Insert button (at the top-right) is clicked.

In the example shown in the screenshot, clicking the Insert button would result in the following lines being inserted into the test script (assuming we are using Python—the code for other languages is very similar):

test.compare(waitForObjectExists(":Invoice:_QComboBox").currentText, "AXV-12200")
test.compare(waitForObjectExists(":This Payment:_QSpinBox").value, 350)
test.compare(waitForObjectExists(":Make Payment.Credit Card_QRadioButton").checked, True)

If we wanted to do these same verifications in hand written code we could write the same as the above, but in practice we do things in a different style by hand and would instead do this:

comboBox = waitForObject(":Invoice:_QComboBox")
test.compare(comboBox.currentText, "AXV-12200")
spinBox = waitForObject(":This Payment:_QSpinBox")
test.compare(spinBox.value, 350)
radioButton = waitForObject(":Make Payment.Credit Card_QRadioButton")
test.verify(radioButton.checked)

We can invert the meaning of a verification shown in the view by checking the Expected Failure checkbox and changing the value to one we do not expect. To continue the example shown in the screenshot, we could set the radio button's checked value to “false” and check the associated Expected Failure checkbox. This would make Squish generate a call to the test.xcompare function rather than to the test.compare function and to use a value of false in the comparison.

If we change our minds and don't want to insert a particular verification we can simply click its associated Delete button. And if we want to delete a verification after it has been inserted we just need to delete the one or two lines of code that do the verification in the test script's code.

By default verifications are inserted as “Scriptified Properties VP”s—this just means that they are inserted as code as shown above. This is by far the most convenient way to insert verifications because it makes them easy to read and easy to modify or delete.

It is also possible to insert a verification as a “Properties VP”—this creates a new resource in the Test Suites view (Section 8.2.19)'s Test Case Resources list (in the VPs tab) called “VP1” (or “VP2” if VP1 exists, etc.). Such verifications are inserted into the test script as calls to the test.vp function with the name of the verification point being passed as the sole parameter. The name can be changed by invoking the context menu on the verification point in the Test Suites view (Section 8.2.19)'s Test Case Resources list—if you do this, make sure that the name used in the call to the test.vp function is the same. If you delete a verification from the Test Suites view (Section 8.2.19)'s Test Case Resources list, you must also delete any associated calls to the test.vp function that refer to the deleted verification.

Squish supports a third kind of verification, “Screenshot VP” as the screenshot below illustrates.

The Verification Point Creator view with a Screenshot VP

To create a screenshot verification double-click the object you want a screenshot of in the Application Objects view (Section 8.2.1). This could be the entire application (i.e., if you click the top-level object), or just one widget (as here where we have double-clicked a spinbox). Screenshot verifications are very similar to Property verifications: they appear as resources in the Test Suites view (Section 8.2.19)'s Test Case Resources list and are invoked by a call to the test.vp function. Just as with Property verifications they can be renamed (in which case the name used in the test.vp function call must be changed to match), or deleted (in which case the test.vp function call must also be deleted).

In general it is much more reliable doing property verifications that screenshot verifications since the latter can be affected by all kinds of irrelevant influences. For example, a change to a computer's theme might mean that a different font is used or that widget borders are thinner, thicker or differently colored than before, and so on. So, here for this example, it is much better to verify the amount (350) than to use a screenshot verification.

See also, How to Create and Use Verification Points (Section 5.22) and the Verification Functions (Section 6.3.8).

The Video Player view is shown in the Squish Test Management Perspective (Section 8.1.2.2). It allows replaying of videos that have been captured as part of the test execution, using the test.startVideoCapture or the Playback option --enable-video-capture (Section 7.4.3.8). This view can be opened or activated by double-clicking on a video attachment or using Jump to Video at Timestamp... toolbar button () or context menu in Test Results view (Section 8.2.18)

The Video Player view

The Video Player view provides common actions for controlling the video playback, including a Play/Pause button (,) to interrupt the video playback, buttons for jumping forwards () and backwards () a few seconds, and a Stop button to end video playback completely (). The current position of the video is displayed as a time offset from the beginning, next to the duration of the complete video. The slider at the right allows seeking to a specific point in the video and also resembles the current position of the video.

The video playback can be optionally synchronized with the selection in the Test Results view (Section 8.2.18) and vice versa. This view setting can be changed in the view's toolbar menu indicated by three vertical dots by toggling Synchronize with Test Report menu entry () on/off.

The Video Player view with synchronization menu opened

When the synchronization is enabled, it works in both ways: the selected item in the Test Results view is automatically updated to follow the video playback. Similarly, as the user selects items in the test result view, the playback fast forwards or rewinds to the corresponding position in the video.

Using the Settings dropdown () it is possible to adjust the playback speed. This allows you to observe quickly done interactions more closely, or to run faster through longer periods of no interactions in the video.