One commonly encountered problem is that many applications change the texts used by some widgets. For instance, a button's text might change from Pause to Resume and back again, or the application might put the name of the current file or workspace in the main window's title bar caption. For example, lets assume that we have the following real name for a fictional MainWindow object in our application with the caption “UsefulApp v1.3 - July Sales.dat”:

{caption='UsefulApp v1.3 - July Sales.dat' type='MainWindow'}

This multiple property name will match the first object in the application which is of type MainWindow and whose caption matches the one shown above.

Such names work perfectly well in most situations and they are generated automatically when recording a test (see Object Name Generation (Section 16.11) for more information on that topic). Unfortunately, since the caption's text is variable it is vulnerable to changes—for example, if we start testing the 1.4 version of the application or if we want to switch to testing a different data file. In either of these cases the caption text will change, and any existing tests that rely on it will now fail.

By default, Squish uses exact matching for property values using the = (equality) operator. However, Squish also provides two other matching operators, ?= (wildcard) and ~= (regular expression, or “regex”).

If we wanted to make the MainWindow's real name more robust we could use the wildcard or the regex operator. Here is an example using the wildcard operator:

{caption?='UsefulApp*' type='MainWindow'}

We'll formally describe the wildcard syntax in a moment, but for now we will just explain what the example means. This says that the 'caption' property's text must begin with “UsefulApp” followed zero or more other characters. (A * stands for zero or more of any characters—so here we expect it to match, “ v1.3 - July Sales.dat” or “ v1.4 - August Sales.dat” or similar. Clearly this is a lot more robust than using the = (equality) operator, although we do have to learn a few symbols (actually, just ?, *, \, [ and ]) to take advantage of this facility.

We could of course achieve the same thing using the regex operator, for example:

{caption~='UsefulApp.*' type='MainWindow'}

This regex match has exactly the same meaning as the wildcard match described above, although in general the regex syntax is much more complicated—and also more versatile—than the wildcard syntax.

The = (equality) operator is used for exact matches. This kind of matching can be used in all situations, and is the only kind of matching that is allowed for the type property and for properties whose value is an object (i.e., is specified using a real name). Here is an example:

{type='LineEdit' visible='1' buddy={type='Label' text='Forename:'}}

This real name is used to identify an object of type LineEdit that has a 'visible' property set to true (1) and that has an associated label—a 'buddy'—which in turn is specified using a real name.

The ?= (wildcard) operator is used for inexact matches. This kind of matching cannot be used for the type property or for properties whose value is an object (i.e., is specified using a real name).

When wildcard matching is in force the ?, *, [, ], and \ characters all take on special meanings and are not matched literally. All other characters are matched literally, i.e., they stand for themselves.

Here is an example:

{type='LineEdit' visible='1' buddy={type='Label' text?='Name*\?'}}

This real name is used to identify an object of type LineEdit that has a 'visible' property set to true (1) and that has an associated label—a 'buddy'—which in turn is specified using a real name. But here the buddy's name is specified using wildcard matching and must contain the text “Name” followed by zero or more other characters followed by a literal “?”.

Here's a second example:

{caption?='UsefulApp v[1-9].[0-9] - ?*.[dD][aA][tT]' type='MainWindow'}

Here, the 'caption' property must have a value that starts with the literal text “UsefulApp v” followed by a digit (but not including zero), then a period, then another digit, then a space, a hyphen, and a space, and then at least one character (indicated by the ?), then zero or more other characters (due to the *), followed by “.dat” (in upper- or lower-case). Notice that if we had specified the filename part of the caption as *.[dD][aA][tT] it would have matched the suffix alone, i.e., “.dat” since the * symbol can match zero characters. By starting with the ? we ensure that at least once character is matched in front of the suffix.

The ~= (regex) operator is used for inexact matches. This kind of matching cannot be used for the type property or for properties whose value is an object (i.e., is specified using a real name). Regex matching allows us to write more sophisticated—and potentially harder to understand and maintain—matching expressions than can be achieved using wildcard matching. In fact we recommend using wildcard matching where possible simply because it is easier, both to read and write.

For Squish for Web editions the regex syntax is the same as the one supported by JavaScript. Documentation for this syntax is available from Regular-Expressions.info and w3schools.com. For all other Squish editions the Qt QRegExp syntax is used—this is documented here: QRegExp.

Which properties does a particular object have that can be used for identifying an object? The answer is not straightforward because the properties are discovered dynamically.

To take the Qt toolkit as a typical example: Squish exposes all the object's base class's properties (i.e., QObject's properties), also any object-type-specific properties that have been added by the supplier or by the AUT (e.g., through subclassing), and finally some artificial properties that are especially useful to Squish.

In general, all of an object's properties are potentially usable for identifying it (e.g., using them in a real name in calls to the findObject and waitForObject functions). However, only the non-artificial properties are suitable for use in verifications (e.g., in calls to the test.compare function and other test module functions).

To find out what an object's non-artificial properties are, either look up the object's type in its toolkit's documentation or use the Spy. To use the Spy begin by launching the AUT (see the "Launch AUT" action (Section 17.1.1.22)), then interact with the AUT until the relevant AUT object is visible. At this point context switch back to the Squish IDE and invoke the pick action (see the Application Objects view (Section 17.2.1)); and pick the object of interest. Now all the object's non-artificial properties will be shown in the Properties view (Section 17.2.10). To find out the object's artificial properties, invoke the context menu on the object in the Application Objects view (Section 17.2.1) and copy its real name to the clipboard: any properties in the real name that are not listed in the Properties view (Section 17.2.10) are artificial properties.