The Application Objects view is shown in the Squish Spy Perspective (Section 16.1.2.1) and the Squish Test Debugging Perspective (Section 16.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 16.2.11). 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 ().

If you want to access the name and properties of a particular widget, 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 16.2.11) 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 Application Objects view provides a context menu with three options: Copy to clipboard (Real Name), Copy to clipboard (Symbolic Name), and Add to Object Map. 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.

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

The Breakpoints view is not shown in any perspective by default. It can be shown by using the Show View action (Section 16.1.1.63) 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 16.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 16.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 16.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 Console view is shown in the Squish Test Debugging Perspective (Section 16.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 Console view has access to the AUT's objects and to the scripting language used by the test suite—but it does not have access to any variables that are created in the test case's test script. This isn't a limitation in practice since we can simply use the findObject to get a reference to AUT objects we want to interact with as the screenshot shows. We can add information to the Test Results by calling appropriate test module functions such as the test.log.

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 16.2.6)'s Text Area Context Menu table for details), or chosen by using the Show View action (Section 16.1.1.63). 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 16.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 16.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 16.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 16.1.1.55).
	Suspend	Invokes the Suspend action (Section 16.1.1.74)—this action is not needed or functional in the Squish IDE.
	Terminate	Invokes the Terminate action (Section 16.1.1.76).
	Disconnect	This action is not functional in the Squish IDE.
	Step Into	Invokes the Step Into action (Section 16.1.1.71).
	Step Over	Invokes the Step Over action (Section 16.1.1.72).
	Step Return	Invokes the Step Return action (Section 16.1.1.73).
	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 16.3.11)—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 16.1. Line Number Context Menu

Context Menu Option Name	Action
Toggle Breakpoint	Invokes the Toggle Breakpoint action (Section 16.1.1.78).
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 16.1.1.47)
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 16.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 16.3.11) 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 16.3. Text Area Context Menu

Languages	Context Menu Option Name	Action
JavaScript, Perl, Python, Tcl	Undo	Invokes the Undo action (Section 16.1.1.82).
JavaScript, Perl, Python, 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 16.1.1.82).)
JavaScript, Perl, Python, Tcl	Save	Invokes the Save action (Section 16.1.1.57).
JavaScript, Perl, Python, 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 16.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, Tcl	Show in	This menu option (also invokable by pressing Shift+Alt+W) is not functional in the Squish IDE.
JavaScript, Perl, Python, Tcl	Cut	Invokes the Cut action (Section 16.1.1.12)
JavaScript, Perl, Python, Tcl	Copy	Invokes the Copy action (Section 16.1.1.10)
JavaScript, Perl, Python, Tcl	Paste	Invokes the Paste action (Section 16.1.1.37)
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, Tcl	Source	This menu option has a submenu with options shown in Table 16.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 16.1.1.60) 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, Tcl	Run As	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Tcl	Debug As	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Tcl	Team	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Tcl	Compare With	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Tcl	Replace With	This menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Tcl	Record Snippet	Invokes the Re­cord Snip­pet action (Section 16.1.1.47)
JavaScript, Perl, Python, 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 16.1.1.82) if you change your mind.)
JavaScript, Perl, Python, 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 16.1.1.82) 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, Tcl	Preferences	Pops up the Pref­er­ences dialog (Section 16.3.11) showing the preferences for the current editor view's type (e.g., Python editor, Tcl editor, etc.)
JavaScript, Perl, Python, 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 16.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 16.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 16.2.17).

Advanced

Global scripts are an advanced feature introduced in Squish 4.1. 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 16.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 Methods view is shown in the Squish Spy Perspective (Section 16.1.2.1) and the Squish Test Debugging Perspective (Section 16.1.2.3). It shows the methods that can be called by the object highlighted in the Application Objects view (Section 16.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 Object Map view is not shown in any perspective by default. It can be shown by clicking the Test Suites view (Section 16.2.16)'s Object Map toolbar button. The Object Map view can be used to add, edit, and delete entries from the test suite's objects.map file.

The Object Map view

	Plain Text File Format
	The objects.map files are plain text, so in theory can be edited in any plain text UTF-8 savvy editor, but we recommend editing using the Object Map view for safety.

The Object Map view is split into an upper and a lower panel. The upper panel is labelled “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 labelled “Name Properties” and shows the properties associated with the highlighted symbolic name.

In the screenshot the highlighted symbolic name is ":CSV Table.File_QTableWidget". By looking at its properties we can construct its real (multi-property) name: "{aboveWidget=':CSV Table.File_QToolBar' type='QTableWidget' unnamed='1' visible='1' window=':CSV Table_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 just have to 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.

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 action to be performed in the Object Map is to edit an existing symbolic name's properties. For example, you might have an object with a title property whose operator is set to Equals and whose value is set to “Edit”, but whose value actually changes in some contexts. Squish will detect this and create separate symbolic names for each case, but if you want to use one symbolic name for all cases you could edit its title property—for example, by setting its operator to Wildcard and its value to “Edit*” so as to match “Edit”, “Edit New”, or any other text that begins with “Edit”. (For more about matching object names see Improving Object Identification (Section 15.8).)

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.

The Object Map view has a context menu with some standard actions (specifically, the Copy action (Section 16.1.1.10), the Cut action (Section 16.1.1.12), the Paste action (Section 16.1.1.37), and the Delete action (Section 16.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. If the AUT is running (e.g., is at a breakpoint or has been started with the Launch AUT action (Section 16.1.1.22)), the Check Object Existence option will be enabled: use this to see if an object with the selected symbolic name exists. (It might not exist right now if it is created later on in the test run.)

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

The Outline view is not shown in any perspective by default. It can be shown by using the Show View action (Section 16.1.1.63) 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 16.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 16.1.2.1) and the Squish Test Debugging Perspective (Section 16.1.2.3). It shows the properties of the Application Objects view (Section 16.2.1)'s selected object.

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 16.1.2.3) is active), clicking a property will make the Verification Point Creator view (Section 16.2.19) 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 16.2.19)'s Insert button.)

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

The Runner/Server Log view is not shown in any perspective by default. It can be shown by using the Show View action (Section 16.1.1.63). It shows all the actions taken by the squishrunner and squishserver, for example, as a test case is run.

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 Search view is not shown in any perspective by default. It can be shown by using the Show View action (Section 16.1.1.63); 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 16.1.1.85) (by pressing Ctrl+Alt+G) when the cursor was on a function called addNameAndAddress in an Editor view (Section 16.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 16.2.6) (opening a new tab with a new file if necesary). This action can be invoked by pressing Ctrl+. (which when the Search view isn't active normally invokes the Next Annotation action (Section 16.1.1.30).)
	Show Previous Match	Moves the highlight to the previous match in the view and also makes the match visible in the Editor view (Section 16.2.6) (opening a new tab with a new file if necesary). 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 16.1.1.39).)
	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 Settings view is not shown in any perspective by default. It can be shown by clicking the Test Suites view (Section 16.2.16)'s Test Suite Settings toolbar button. It is used to view and edit test suite-specific information.

The Setting view (Test Suite Information and AUT)

The Test Suite Information is set when the New Squish Test Suite wizard (Section 16.3.9) is used to create a new test suite: it cannot be changed.

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.) For Squish 4 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. (In Squish 3 this checkbox was normally checked so no call to the startApplication function was needed; however, this is less versatile than the approach adopted by Squish 4.)

The Setting view (Working Directory and Environment)

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 15.3.3), Setting Environment Variables for the AUT (Section 15.3.3.1), and Environment Variables (Section 15.5).)

The Setting view (Test Case Order and Object Map)

The Test Case Order lists the test suite's test cases in the order they will be run in if you click the Run Test Suite toolbar button (), or if you run the tests from the command line using squishrunner's --testsuite option. (See also, Executing Test Cases (Section 15.4.1.3).) The order can easily be changed by clicking a particular test case and then clicking the Up or Down button as often as necessary to reposition the test case in the list. Simply repeat this process until all the test cases are listed in the order you want. Note that the Test Case Order list is only present in Squish IDE 4.0.0 and 4.0.1; for 4.0.2 and later reordering test cases is done by dragging and dropping them in the Test Suites view (Section 16.2.16)'s Test Cases list.

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 16.2.9). For information about handling the Object Map programmatically in test scripts see Object Map Functions (Section 14.3.10). For more about Object Maps in use see the Object Map (Section 15.9).

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

The Test Results view (Squish 4.0)

By default the view shows every kind of result: passes, fails, warnings, and so on. All these are controlled by the view's toggle buttons which are all on by default. Toggle any of them off if there are some categories that are not of interest.

The view has a context menu that supports the Select All action (Section 16.1.1.61) and the Copy action (Section 16.1.1.10). It also supports a Clear action that deletes all the entries shown and an Export Results action that pops up a file save dialog. You can use the Export Results action to save the results in XML format (the default is Squish's version 2.1 XML format). Files in this format can be converted to HTML; see Converting XML Test Results to HTML (Section 13.22.1.2).

The Test Results view and the Filter Test Results dialog (Squish 4.1)

From Squish 4.1 the Test Results view provides a Filter Results button which when clicked pops up the Filter Test Results dialog. All the checked items in this dialog are shown in the test results, so to filter out unwanted items, simply uncheck their corresponding checkbox.

The Test Suites view is shown in the Squish Test Management Perspective (Section 16.1.2.2) and the Squish Spy Perspective (Section 16.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 16.1.1.29), the Open Test Suite toolbar button () which invokes the Open Test Suite action (Section 16.1.1.35), the Test Suite Settings toolbar button () which makes the Settings view (Section 16.2.14) visible, and the Object Map toolbar button () which makes the Object Map view (Section 16.2.9) visible.

The Test Cases list also has toolbar buttons to its right. The first is the New Test Case toolbar 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 16.1.1.82) 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 16.1.1.47). To view or edit a test script in an Editor view (Section 16.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 14.3.9).

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 16.3.11)'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 16.3.5)'s Squish Test Case from Template option. (See also Creating a New Template (Section 15.12.1).)

The Test Summary view is shown in the Squish Test Management Perspective (Section 16.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 16.1.1.61) and the Copy action (Section 16.1.1.10).

The Variables view is shown in the Squish Test Debugging Perspective (Section 16.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 16.1.1.61), 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 16.2.11) (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):

waitFor("object.exists(':Invoice:_QComboBox')", 20000)
test.compare(findObject(":Invoice:_QComboBox").currentText, "AXV-12200")
waitFor("object.exists(':This Payment:_QSpinBox')", 20000)
test.compare(findObject(":This Payment:_QSpinBox").value, 350)
waitFor("object.exists(':Make Payment.Credit Card_QRadioButton')", 20000)
test.compare(findObject(":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 16.2.16)'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 16.2.16)'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 16.2.16)'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 16.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 16.2.16)'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 13.20) and the Verification Functions (Section 14.3.8).