As Reginald previously mentioned Squish 3.2 is going to have an even more sophisticated technique for identifying objects based on some properties. This is achieved by allowing to determine whether a given object matches a given property value not only through a plain string comparison but by also testing whether the object matches a certain regular expression or wildcard-enhanced string.
I just finished implementing a first version of the same powerful magic for Web tests and so far (keeping fingers crossed) it seems to work well without introducing any regressions. Using regular expressions and/or wildcards when patching property values is especially useful for Web tests, since many Web applications happen to encode some more or less random session ID into important attributes.
For instance, we have seen cases were the object map for a recorded Squish test contained entries along the lines of
Playing the very same test didn’t work, since on the next run all id= attributes of the elements were composed with a different dynamic ID. With Squish 3.2, there’s a very simple way to solve this issue.
Either use wildcards:
…or use regular expressions:
Note how the ‘id=’ becomes ‘id?=’ to indicate that the given value is supposed to be interpreted as a wildcard string, or ‘id~=’ to indicate that the string is a regular expression. After tuning the object map entry like that, your test will play back nicely, no matter what the session ID might be.
For what it’s worth, sticking to simple wildcard strings (which just have ‘*’ to denote ‘any string’ or ‘?’ to denote ‘any character’ – much like on the Windows command line) is probably sufficient in most cases, but it doesn’t hurt to have the full expressive power of regular expressions in case wildcards just don’t cut it.