Coded UI Test enabled Cross Browser testing with Visual Studio Update 1. You can have a look at this link for some introduction on for cross browser testing. As part of Visual Studio Update 2, several enhancements were added to this feature. One of them, being smart match for top level windows in cross browser testing. Coded UI Test already had this top level window smart match enabled for other technologies, smart match was brought on par with this for Firefox and Chrome. You can have a look at the initial post for this feature posted by Anutthara.

Below is a brief description of the scenarios and small insight into the heuristics applied for smart match.

It is very common to have scenarios in Web Applications where part of the title remains constant and the other changes.

For example, when reading email the title could be “Inbox(35) – Google Chrome” (corresponding titles  “Inbox(36) – Microsoft Internet Explorer” or “Inbox(35) – Mozilla Firefox”)

Of course, the part after the title, i.e., name of the browser as highlighted above is already always handled. The name of the browser is not a part of the title in the generated code, and we recommend you do not include it while hand-coding as well.

 This feature will help you identify a window whose title probably changes and appears as any of the following:

• Inbox(35) – Google Chrome
• Inbox(40) – Google Chrome
• Inbox (35)   –   Google Chrome (notice the extra spaces)

How the heuristics work: 

1)   Whichever window has the longest common string will have a higher score. Example: “Inbox, 45 unread” and “Inbox, 46 unread” will be a 50% match because the longest common string is 8(Inbox, 4) out of the total length of 16. On the other hand, “Inbox, unread(45)” and “Inbox, unread(46)” will be excellent matches because the longest common string is 15 out of 17.

2)   If two or more windows get a good score, the window on the top is picked up.

Sometimes of course smart match can end up getting you false positives; those scenarios can be worked around.

Also remember, smart match tends to make your automation a bit slower, since it’ll try to find the best match window if exact match does not exist. 

TIP:

If you know a part of the web page title will always change, it’s best to exclude that part in the search property and do a contains based search.

In the above example, generated code for the top level window would look like:

this.SearchProperties[UITestControl.PropertyNames.Name] = “Inbox(35)“;

Using the Coded UI Test Editor as explained here to change the property, it would look like:

this.SearchProperties.Add(new PropertyExpression(UITestControl.PropertyNames.Name, “Inbox“, PropertyExpressionOperator.Contains));

This way the window would be found in the first pass, saving overhead of smart match.

We hope to have made the playback much more resilient across web applications with this enhancement in cross browser testing with Coded UI Test!