Glossary

AUT

This is the Application Under Test, that is, the application that is to be GUI-tested by Squish.

Connection (MBT)

A directed relation between a source and a target MBT Step. It is visually represented as an arrow between two steps indicating the direction.

Feature (BDD)

Corresponds to a Gherkin file with a .feature extension. Contains 1 or more Scenarios.

Hook

1. (Squish, Noun) a small library that makes the AUT's live running objects accessible, and allows communication with squishserver. This functionality is provided to AUTs through the use of start*aut for some configurations. In cases where the tool does not work, it might be necessary to add a Built-in Hook to your AUT.
2. (Squish, Verb) To connect to the Squish Hook, which can be done from startApplication or attachToApplication.
3. (BDD, Noun) a function that can be called under certain circumstances, such as at the start or end of a Feature, Scenario, or Step. See BDD Hooks for details.

Image Group

An Image Group in Squish is a collection of images that are considered "equivalent" when considered for image searches/verifications. Perhaps the images in the group are of different resolutions or color schemes, but each of the images represents the same concept. Under the covers, an Image Group is simply a folder/directory in searchImages at the previous location of its first image.

Adding or removing an image from an Image Group can be achieved with any file manager, or a drag-and-drop operation from the IDE in Test Suite Resources - Search Images.

Image Search

Using findImage, test.imagePresent, or waitForImage means using the Image Search feature of Squish. These functions support Image Groups and are more flexible than the old XML-based ScreenShot Verification Points.

See How to do Image-Based Testing for more details.

Model (MBT)

An abstract representation of a test basis. It can be used to model different aspects, such as the test itself, a workflow, the behavior of the AUT, or test data.

Path (MBT)

A concrete way through a given MBT model. It describes which steps are taken through a model-based test. The model should not contain invalid paths - performing consecutive steps in a path should not lead to failures if the AUT works correctly.

Object Map

A mapping of Symbolic Names to Real Names. If it is Script-Based, then we can find it in a file called names.py, names.js, names.pl, names.rb or names.tcl under the shared/scripts directory in a test suite. If it is Text-Based, objects.map is used. A Test Case can use a mixture of text-based and script-based object names, as long as both are defined in the test suite.

OCR

Optical Character Recognition - In Squish's case, using an external program to analyze pixel image data and recognize text in it.

Real Name, or realname

A mapping of name-value pairs, where the name is a property and the value can be a simple value, or if it is a string, can be a regex or a wildcard. realnames are used for lookup of objects in functions like waitForObject(). They describe a query, or set of constraints used for object search.

There are Script-Based realnames, and Text-Based realnames. Script-Based are native (to the script language) dictionaries. Text-Based realnames are encoded as a string, which is not script-language dependent.

Scenario (BDD)

A named sequence of Gherkin Steps describing a BDD Test Case.

SquishRunner

The process that reads and writes test scripts, and writes test results. It communicates with the SquishServer and the AUT using TCP/IP.

SquishServer

The process that starts and stops the AUT or browser, and establishes a communication hook for SquishRunner to use. Also used for attaching to running AUT, possibly on a remote machine, and started with start*aut.

SQUISHDIR

This is the directory where Squish is installed on your system. By default, the install location on Windows is under %USERPROFILE%. On macOS, it is under Applications.

Squish Step Diagram (MBT)

A diagram representing an MBT model or just its part. The diagram is intended to focus on the workflow of the application and not the data. It consists of Steps and connections between them. Each connection shows a possible sequence in which steps can be performed.

Squish User Settings Directory

This is the directory where Squish reads and writes its user settings. By default, it is %APPDATA%\froglogic\Squish on Windows and ~/.squish on other systems. It can be changed by setting the SQUISH_USER_SETTINGS_DIR environment variable.

Step

An activity that should happen during a Test Case.

• (MBT) Visually represented by rounded rectangles with a descriptive name inside. A Test Case is a Path of Steps.
• (BDD) Usually starts with a Gherkin keyword such as Given, When, And, Then, and is followed by a name, which is later implemented as a step function. A Test Case is 1 (or more) Scenario(s) of Steps.

Symbolic Name

When using the Script-Based Object Map, a Symbolic Name is a variable name, defined in the shared/scripts/names.xy file. The value of that variable is a native dictionary, which contains the realname of that object.

When using a Text-Based Object Map, a Symbolic Name is a string, beginning with :. For example, ":Forename:_LineEdit". The symbolic name and its corresponding value can be found on a tab separated line, in a file called objects.map.

Synchronization

Using a waitFor* function to tell Squish to wait until a certain object or item is ready. Or using a snooze() function. Generally, these are things that slow down the execution of Squish's test runner, to allow the AUT to catch up to it.

Synthetic Properties

Properties which were not in the API of an object's class, but were added by Squish to a widget, for convenience, or to help disambiguate during object lookup. See Synthetic Properties for more details.

Test Basis

The body of knowledge used as the foundation or starting point for creating test cases and designing test scenarios.

Test Case

A Test Case, or Test for short, can be

1. Script-based, where the Steps are functions and statements in a script language.
2. BDD, where the Steps are described in a higher level Scenario, using a Gherkin .feature file.
3. MBT, where the Steps are described as a Path of Connections through a graphical Model (MBT).
4. Keyword-Driven, where the Steps are described as rows in a table of data.

Test Suite

A collection of Test Cases, grouped together by a common parent folder, and a having suite.conf configuration file there. It has a shared/ folder for things that are shared between test cases. A Test Suite may contain different kinds of Test Cases, and use multiple Toolkits, but may use only one script language.

TMTOWTDI

There is More Than One Way To Do It. Originally coined by Larry Wall, inventor of Perl.

Widget

As far as Squish is concerned, this is a (historical) generic term which usually means any GUI component from any toolkit, that is automated by Squish. It is not necessarily something derived from QWidget.

Wrapped Class

A Wrapped Class is one that can be used from a Squish test case because there is a Wrapper class for it, packaged in a Wrapper Library, for the chosen script language.

Wrapper

Usually, the word Wrapper refers to a specific supported toolkit.

In suite.conf there is a WRAPPERS= line. This corresponds to the radio button in the New Test Suite wizard that selects which Wrapper/Edition to use (Qt, Mac, Windows, Java, Android, iOS, VNC, etc).

Wrapper Library

Squish supports different toolkits through the use of Wrapper Libraries, which are usually named after the toolkit, and support the same API as the underlying toolkit library. A Wrapper Library is a collection of Wrapper Classes.

Squish for VNC does not use Wrapper Libraries at all because the "Virtual AUT" is the entire device's display.