Troubleshooting tips for cross browser testing in Coded UI Test
I assume in this blog that you have basic knowledge of cross browser testing with Coded UI Test. You can visit this link which introduces cross browser testing with Coded UI Test , and also calls out the known limitations with this release. I also assume you are familiar with Coded UI Test Html logs used for troubleshooting. This link is a good place to see an introductory session on troubleshooting your cross browser tests with Html Logs.
Here, I will enumerate some common failure scenarios and how to fix them:
(I) Search Failure:
The playback failed to find the control with the given search properties. Additional Details:..
You may get additional info about control search properties specified in test code from the Html logs, which will turn up as follows:
Validating if the element with specified properties exists in the page:
This is the first thing we would want to validate. Locating control in IE is straightforward by using the CodedUITestBuilder. However, locating controls on Firefox/Chrome using builder is not supported. You may inspect the properties of the control of interest in the other browsers using the corresponding Developer tools.
Example, on Chrome, bring up the Developer Tools by pressing F12.
Click on the inspect button (highlighted in red above) to inspect your controls. In the image above, I have clicked on the search edit box on the Bing home page which also brings up details of the control in the dev tool window. This means that the control exists on the page but might be something to do with properties of the control
Here you can compare the properties that had been generated for that control in Coded UI test, vs. the one actually on the page. Here we can see that id and name are different from the ones specified in test code, and can fix it accordingly.
Frequently occurring scenarios:
The search property changed since the last browsing session.
Some pages generate random id’s for the html elements. If you know the nature of application is such that “Id” would not be a reliable search property, you can exclude this as a search property using the IE Property Configuration xml as shown below: (Similarly, for other search properties)
<Property Name=”Id”/> (remove this line)
Moving a filter property to search property makes the search pass.
In the CrossBrowser plugin, we currently respect only TagInstance as a filter property for Chrome and Firefox, other filter properties are ignored. Some controls such as Pane may have insufficient primary properties, such as null values for id and name. Here moving the InnerText/ClassName from Filter to Search property may work. All you need to do is access the control properties from Coded UI Editor and delete say InnerText property from Search Properties Collection and add the same to Filter Properties collection. (Reference this link for details)
Note: InnerText search is .Contains based, so you may specify a substring of the entire InnerText if you think only that part remains constant across sessions.
Element does not exist in cache
The control may actually be visible on the page but selenium API throws an error like following error like: “****** execution failed; Element does not exist in cache” (This error log may be tricky to find. You can enable tracing and look at the playback logs)
To work around this, use the WaitForControlExist API on the control being searched.
HtmlEdit editbox = new HtmlEdit (browser);
editBox.Text = “Waited for Control to appear”;
Search failure if the control appears after a delay due to AJAX request:
Since we currently do not track AJAX requests in our WaitForPageToLoad logic, it could be that the control itself appears after a delay. This should be simple to figure out using the snapshot in the Coded UI Test Logs. As mentioned in the last point, you can work around this by using the WaitForControlExist API on the given control.
(II) Blocked control exception:
Inner exception: Element did not receive the click, other element would receive the click.
Use the dev tool bar (as explained before) for that browser to locate the control. If the bounding rectangle of given control is such that it is overlapped by another control, you may not be able to click it.
1. Do a relative coordinate click.
This is not enabled by default for Chrome/Firefox. It can be enabled by using the following setting:
Mouse.Click(control, new Point(x,y)); Environment.SetEnvironmentVariable(“CUIT_SELENIUM_CLICKCOORDINATEBASED”,false);
2. Handcode around the scenario:
Ensure that there is a control in the hierarchy which is clickable and has the same effect as clicking the intended control. Hand code the related control and use the Mouse.Click API
(III) Some known limitations:
- Launching a new web page in the test code opens the page in a new tab for chrome.
You may not always hit this issue, and should be fixed in the next release. Meanwhile you can rename your default folder saved for the chrome session. This is picked from your Local App data info (Given by %LOCALAPPDATA%\ Google\Chrome\Default). Rename the highlighted folder to get this working properly.
You may also encounter a chrome driver crash issue on end of test (related to selenium dependency). This is an intermittent issue. This should not hamper your test execution, and should be fixed with the next release.
2. “No response from server for url” for slow loading pages on Firefox/Chrome.
We’ve tried to handle this in the next release. The workaround would be to ignore (eat) the exception meanwhile, if you know that an action results in a navigationwhich will take a long time (greater than a minute or so).
3. Selenium WebDriver doesn’t handle the print dialogs, save dialogs and other OS dialogs.
Dialogs such as a print dialog vary across browsers and handling needs to be done in the test code. You will need to dismiss the dialog through code and continue with the next set of actions.