8.2. Views

8.2.1. Application Objects view
8.2.2. Breakpoints view
8.2.3. Console view
8.2.4. Call Hierarchy view
8.2.5. Debug view
8.2.6. Editor view
8.2.7. Global Scripts view
8.2.8. Methods view
8.2.9. Object Map view
8.2.10. Outline view
8.2.11. Properties view
8.2.12. Runner/Server Log view
8.2.13. Search view
8.2.14. Settings view
8.2.15. Test Results view
8.2.16. Test Suites view
8.2.17. Test Summary view
8.2.18. Variables view
8.2.19. Verification Point Creator view

The Squish IDE provides many different views. Most of the views are shown by default in one perspective or another, but some can only be made visible by explicitly showing them—for example using the Show View action (Section 8.1.1.62).

In this section we document all the views that are visible in the Squish IDE, plus some common ones that are not visible by default but that you might want to use.

8.2.1. Application Objects view

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.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 ().

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 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 8.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 view's Highlight Object toolbar button () allows to 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).)

8.2.2. Breakpoints view

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+QB. 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.

IconToolbar Button NameAction
Remove Selected BreakpointsRemoves the selected breakpoints.
Remove All BreakpointsRemoves all the breakpoints—this can also be done by invoking the Remove All Breakpoints action (Section 8.1.1.51).
Show Breakpoints for Selected TargetThis toolbar button is inherited from Eclipse; it is not functional in the Squish IDE.
Go to File for BreakpointMakes 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 BreakpointsA 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 AllExpands all the entries shown in the view if they are being shown as a tree rather than as a list.
Collapse AllCollapses all the entries shown in the view if they are being shown as a tree rather than as a list.
Link with Debug ViewThis toolbar button is inherited from Eclipse; it is not functional in the Squish IDE.
View MenuThis 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.

8.2.3. Console view

The Squish ScriptConsole 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 ScriptConsole basically allows to do everything that can be done in the test script itself, except that access test script variables may not be available in every script language, and that changing test script variables is not supported.

8.2.4. Call Hierarchy view

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.

8.2.5. Debug view

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.

IconToolbar Button NameAction
Remove Terminated LaunchesClears the details of any AUTs that have been terminated from the view
ResumeInvokes the Resume action (Section 8.1.1.54).
SuspendInvokes the Suspend action (Section 8.1.1.73)this action is not needed or functional in the Squish IDE.
TerminateInvokes the Terminate action (Section 8.1.1.75).
DisconnectThis action is not functional in the Squish IDE.
Step IntoInvokes the Step Into action (Section 8.1.1.70).
Step OverInvokes the Step Over action (Section 8.1.1.71).
Step ReturnInvokes the Step Return action (Section 8.1.1.72).
Drop To FrameThis action is not functional in the Squish IDE.
Use Step FiltersThis toggle action is not functional in the Squish IDE.
View MenuThis menu provides menu options for controlling how the view presents its data.

8.2.6. Editor view

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.12)—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 NameAction
Toggle BreakpointInvokes the Toggle Breakpoint action (Section 8.1.1.77).
Disable BreakpointDisables the breakpoint at the current line if there is one and it is enabled.
Record SnippetInvokes the Re­cord Snip­pet action (Section 8.1.1.47)
Replace With TestData FieldThis context menu option is currently not functional in the Squish IDE.
Show Quick DiffThis context menu option is currently not functional in the Squish IDE.
Show Line NumbersThis menu option is checkable—if checked the editor shows line numbers; otherwise it doesn't.
FoldingThis 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.
PreferencesInvoking this option pops up the Pref­er­ences dialog (Section 8.3.12) at the editor preferences item for the scripting language being used.
Breakpoint PropertiesThis 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.2. Folding Context Menu

Submenu Option NameKeyboard ShortcutAction
Enable FoldingCtrl+/ on the numeric keypadThis toggle action is used to enable or disable folding.
Expand AllCtrl+* on the numeric keypadExpands all folded items.
Collapse AllShift+Ctrl+/ on the numeric keypadCollapses all unfolded foldable items.
Reset StructureShift+Ctrl+* on the numeric keypadExpands all folded items and reevaluates the file's folding structure.
Collapse Blocks Folds all foldable blocks that aren't functions.
Collapse Comments Folds all foldable comments.


Table 8.3. Text Area Context Menu

LanguagesContext Menu Option NameAction
JavaScript, Perl, Python, Ruby, TclUndoInvokes the Undo action (Section 8.1.1.81).
JavaScript, Perl, Python, Ruby, TclRevert FileThis 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, TclSaveInvokes the Save action (Section 8.1.1.56).
JavaScript, Perl, Python, Ruby, TclOpen DeclarationThis menu option (invoked by F2) is not functional in the Squish IDE.
JavaScript, Python, TclOpen Type HierarchyThis 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, TclOpen Call HierarchyThis 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, TclQuick OutlineThis 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, TclQuick Type HierarchyThis 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, TclShow inThis menu option (also invokable by pressing Shift+Alt+W) is not functional in the Squish IDE.
JavaScript, Perl, Python, Ruby, TclCutInvokes the Cut action (Section 8.1.1.12)
JavaScript, Perl, Python, Ruby, TclCopyInvokes the Copy action (Section 8.1.1.10)
JavaScript, Perl, Python, Ruby, TclPasteInvokes the Paste action (Section 8.1.1.37)
PerlShift RightMoves the current line right two spaces.
PerlShift LeftMoves the current line left two spaces (if possible).
JavaScript, Perl, Python, Ruby, TclSourceThis 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.
PerlRefactorThis 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.
PerlPerldocThis menu option (also invokable by pressing Shift+Ctrl+H) is intended to run perldoc but is not functional in the Squish IDE.
JavaScript, Python, TclSearchThis menu option is not functional in the Squish IDE; however, the menubar Search action (Section 8.1.1.59) provides search facilities
JavaScriptPaste to JavaScript ConsoleThis menu option is not fully functional in the Squish IDE—all it currently does is copy the selected text to the clipboard
TclPaste to TclConsoleThis menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, TclRun AsThis menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, TclDebug AsThis menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, TclTeamThis menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, TclCompare WithThis menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, TclReplace WithThis menu option is not functional in the Squish IDE
JavaScript, Perl, Python, Ruby, TclRecord SnippetInvokes the Re­cord Snip­pet action (Section 8.1.1.47)
JavaScript, Perl, Python, Ruby, TclMake Code Data DrivenThis 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, TclReplace With TestData FieldThis 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, TclPreferencesPops up the Pref­er­ences dialog (Section 8.3.12) showing the preferences for the current editor view's type (e.g., Python editor, Tcl editor, etc.)
JavaScript, Perl, Python, Ruby, TclInput MethodsThis 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


Table 8.4. Source Submenu

LanguagesSubmenu Option NameAction
JavaScriptAdd Block CommentThis submenu option (also invokable by pressing Shift+Ctrl+/) inserts /* before the selected text and */ after the selected text to comment out all the selected text.
JavaScriptRemove Block CommentThis submenu option (also invokable by pressing Shift+Ctrl+\) removes block comments (/* and */).
JavaScript, Perl, Python, Ruby, TclToggle CommentThis submenu option (also invokable by pressing Shift+Ctrl+C; except when in a Perl editor where it is invoked with Ctrl+/) comments out the current line if it is not commented out or uncomments the current line if it is commented out.
JavaScript, Python, TclCommentThis submenu option comments out the current line.
JavaScript, Python, TclUncommentThis submenu option uncomments the current line.
JavaScript, PerlFormatThis submenu option (also invokable by pressing Shift+Ctrl+F) reformats the editor's text—for example, tidying up the indentation
JavaScriptFormat ElementThis submenu option has the same effect as the Format submenu option
JavaScriptCorrect IndentationThis submenu option (also invokable by pressing Ctrl+I) corrects the indentation for the selected lines
JavaScript, Python, TclShift LeftThis submenu option shifts the current line (or the selected lines) left by one indent width (often 4 spaces).
JavaScript, Python, TclShift RightThis submenu option shifts the current line (or the selected lines) right by one indent width (often 4 spaces).
PerlValidate SyntaxThis submenu option (also invokable by pressing Shift+F5) is inherited from Eclipse and is redundant since the Squish IDE automatically highlights syntax errors in the left margin
PerlPod::CheckerThis submenu option (also invokable by pressing Shift+Ctrl+D) checks any Perl POD (Plain Old Documentation) that is in the file and marks any problems
PerlClear Pod::Checker MarkersThis submenu option clears any markers that have been set by running the Pod::Checker
PerlPerl::CriticThis submenu option (also invokable by pressing Shift+Ctrl+C) runs perlcritic on the file and marks any problems
PerlClear Perl::Critic MarkersThis submenu option clears any markers that have been set by running Perl::Critic
PerlClear All EPIC MarkersThis submenu option clears any markers—this includes Pod::Checker markers, Perl::Critic markers, and the Squish IDE's standard syntax error highlighting markers


8.2.7. Global Scripts view

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.17).

[Important]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 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.

8.2.8. Methods view

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.

8.2.9. Object Map view

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.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
[Note]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 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.

In cases where the AUT has changed you might want to check whether the object a symbolic name refers to still exists. This can be done by selecting the name and clicking the Check Existence button. This button is only enabled while an application is running.

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.37), 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. If the AUT is running (e.g., is at a breakpoint or has been started with the Launch AUT action (Section 8.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.)

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 Search for object 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).

8.2.10. Outline view

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+QO. 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.

8.2.11. Properties view

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 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.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 8.2.19)'s Insert button.)

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

8.2.12. Runner/Server Log view

The Runner/Server Log view is not shown in any perspective by default. It can be shown by using the Show View action (Section 8.1.1.62). 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.

8.2.13. Search view

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.

IconToolbar Button NameAction
Show Next MatchMoves 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 necesary). 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.30).)
Show Previous MatchMoves 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 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 8.1.1.39).)
Remove Selected MatchesRemoves any selected matches from the view. This action can be invoked by pressing the Delete key
Remove All MatchesRemoves all the matches shown in the view
Expand AllExpands all the matches shown in the view; this toolbar button is not available if viewing in list rather than tree format
Collapse AllCollapse 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 AgainReruns the search; this may be useful if files have changed since the search was last run
Cancel Current SearchCancels 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 SearchesIf 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 ViewIf 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 MenuThis 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.

8.2.14. Settings view

The Settings view is not shown in any perspective by default. It can be shown by clicking the Test Suites view (Section 8.2.16)'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).)

The Setting view (Test Suite Information and AUT)

The Test Suite Information is set when the New Squish Test Suite wizard (Section 8.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 7.3.3), Setting Environment Variables for the AUT (Section 7.3.3.1), and Environment Variables (Section 7.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 7.4.3.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 8.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 8.2.9). 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.15. Test Results view

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 (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 8.1.1.60) and the Copy action (Section 8.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 ???.

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.

8.2.16. Test Suites view

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.29), the Open Test Suite toolbar button () which invokes the Open Test Suite action (Section 8.1.1.35), the Test Suite Settings toolbar button () which makes the Settings view (Section 8.2.14) visible, and the Object Map toolbar button () which makes the Object Map view (Section 8.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 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.47). 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.12)'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.5)'s Squish Test Case from Template option. (See also Creating a New Template (Section 7.14.1).)

8.2.17. Test Summary view

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).

8.2.18. Variables view

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.

8.2.19. Verification Point Creator view

The Verification Point Creator view appears automatically when we check a property's checkbox in the Properties view (Section 8.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):

Python
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:

Python
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.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 8.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 8.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 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.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 5.22) and the Verification Functions (Section 6.3.8).