All About the Apps
Showing results for 
Search instead for 
Do you mean 

Regular Expressions in UFT

Anonymous_User1 ‎09-09-2013 10:00 AM - edited ‎09-09-2015 03:21 PM

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.



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



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



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.



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



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



There are many external tools for dealing with regular expressions.  A tool I’ve been using a lot recently is 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


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.



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: 




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.*"


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



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!


About the Author


Christoph Franzen
on ‎02-28-2016 11:28 PM

Is the "html tag" special handling also implemented for "html id"? What exactly cause the html tag special handling to be disabled?

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all