Regular Expressions in UFT

This post was written by Motti Lanzkron, from the HP UFT R&D team.

 

Regular expressions (‘regex') are a common feature in many programming languages and utilities.  In HP Unified Functional Testing (UFT), you can use regular expressionsin the descriptions used for object identification but there are a couple of small twists to keep in mind.

 

Motivation

Why use regular expressions in the first place?

 

Regular expressions are useful when an object’s property has a consistent pattern but the details may change over time. For example, if you wanted to identify the price part of a product on your shopping site, you would be ill-advised to use the actual price in the description, such as in this screenshot (look at the ‘innertext’ property):

 

p1.png

 

It’s better to have a description that won’t break the next time this item goes on sale:

 

p2.png

 

The regex here, \$\d+\.\d{2}\*, means "match the string that starts with a ‘$’ character, then contains at least one digit, then a ‘.’ character followed by two digits, and ends with a ‘*’ ".  Our previous string, “$139.99*” clearly matches this.  But if the price were to go down (yay!) to $129.99, the string “$129.99*” would also match the regex, which means that the test will not need to be changed.

 

Tools

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
  - Jamie Zawinski

 

The problem with regular expressions is that they quickly descend into un-maintainability.  While it can be pretty straightforward to write a regex, it’s often very hard to read and understand a regex you wrote yourself, let alone one written by someone else.

 

In order to help a test’s author understand regular expressions, UFT provides the Regular Expression Evaluator (Tools > Regular Expression Evaluator…)

 

p3.png

 

The Regular Expression Evaluator is also available from within the object repository’s value configuration editor (along with a handy regex 'cheat sheet'):

 

p4.png

 

There are many external tools for dealing with regular expressions.  A tool I’ve been using a lot recently is regex101.com which also breaks down and explains the regex it’s evaluating.

 

How UFT is different

When using a regex in a test object description, UFT has a few minor differences from other tools. A few examples of these differences are as follows.

 

Case insensitive

UFT tests are based on VBScript which is a case-insensitive language. For example, the following code works just fine, even though the word ‘index’ appears in a different case three times:

 

    Dim Index
    For index = 1 To 10
        Print INDEX
    Next

 

People using a case insensitive language to write tests naturally expect all aspects of the test to be case insensitive. This is the reason that (in most) places, UFT adds the case insensitive flag to regular expressions that are part of an object’s description.

 

Anchoring

As you can see in the Regular Expression Evaluator screenshot above, a regex can match a substring in the middle of a longer string. This can cause problems in object identification, because the text of a containing object will naturally contain the text of a contained object. So regular expressions in descriptions are anchored to the beginning and end. This is the equivalent of adding ‘^’ at the beginning of the regex and ‘$’ at the end.

 

As an example, let’s say we want to match the dollar part of a price tag, but ignore the cents.  If the dollar amount is $99.95, we want to match the “$99.” part, and ignore the “95”, so that it would also match if the amount was $99.00.

 

According to regular regex rules the regex “\$99\.” should match “$99.95”. However, in UFT this expression will not match the value, because, in UFT, this regular expression means: Look for a ‘$’, then the two digits ‘99’followed by a ‘.’ character at the end of the string. Since the ‘.’ isn’t the end of the string, the match will fail.  If you want to ignore the cents, you must add a wildcard at the end of the regex, like this: “\$99\.\d*”. This expression means: Look for a ‘$’, then the two digits ‘99’followed by a ‘.’ character, and then zero or more digits at the end of the string.

 

Descriptive Programming

When using descriptive programming, all values are regular expressions by default. The reasoning behind this is the assumption that you’re using descriptive programming because the regular description, as seen in the object repository, is not working well for you in this situation.  This mean that your object descriptions are probably dynamic, and regular expressions will serve you better than string literals.

 

There are two ways to write descriptive programming:

 

Inline descriptive programming

Inline descriptive programming is when the property values are written as part of the test line that identifies the object.  For example, the browser title for UFT’s homepage, “Automation Testing | HP® Official Site”, can be matched with: 

 

    Browser("title:=.*HP.*").Refresh

 

In inline descriptive programming, the property values (i.e. the part after the ‘:=’) are always regular expressions and there is no way to tell UFT to try to find a literal match.

 

Using the Description object

You can use a Description object to specify an object’s description:

 

    Set desc = Description.Create()
    desc("title").Value = ".*HP.*"
    Browser(desc).Refresh

 

In this case you can turn the regular expression functionality off by setting the property’s RegularExpression property to false, as follows:

 

    desc("title").Value = "Automation Testing | HP® Official Site"
    desc("title").RegularExpression = False

 

p6.png

 

Note that this allows you to use some values as regular expressions and some as literals.

 

Wait a minute…

Now if you’re a Smart Aleck (like I am) you may be thinking “wait a minute, in a previous post on understanding the web test object model in UFT, you described an optimization UFT uses for html tags and advised adding them to descriptive programming, so wouldn’t a regex html tag nullify the html tag optimization?”

 

Explanation for non Smart Alecks: If UFT tried to get a collection of elements from the browser using a regex value, it wouldn’t work since the browser API expects to get a plain string.

 

      document.getElementsByTagName("T.") // does not return all TR, TD and TH elements

 

Since descriptive programming uses regular expression by default, one might assume that this optimization is not available for descriptive programming users.  We realized this was the case and we actually check if the value of the html tag contains any regular expression characters (i.e. non-alphanumeric characters).  If it doesn’t, we treat it as a normal value and not as a regular expression.

 

In Conclusion

We saw how regular expressions in UFT differ from how they are used in other environments.  These differences are:

  • Regular expressions are case insensitive
  • UFT matches the regular expression against the whole string and not just a substring

We also saw when and how the regular expressiveness of a value can be turned off.

 

 

Leave us a comment in the box below to let us know how you use regular expressions in your tests.

 

 

Thanks to Motti for providing this article!

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation