Bringing you news, technical articles, and other useful content about Visual Studio ALM and Team Foundation Server
More videos »
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:
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:
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.
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)
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.
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”;
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.
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
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.
Looks to be a good blog for troubleshooting cross-browser testing using coded ui test.....
Could you please give an example on how to handle a Chrome browser dialog through code?
For example, a site requires authentication and is done though the "Windows Security" dialog in IE. A similar "Authentication Required" dialog is displayed when the same site is browsed to in Chrome. Please show me how you would handle entering credentials in this Chrome dialog.
Handling Authentication dialogs is not supported currently.
What you can do is record a separate method for dismissing the dialog on Chrome (do a recording on Chrome authentication dialog only). Then call the specific method depending on the current browser.
This should playback fine.
Thanks for the response, Saima.
I've already try recording; it didn't work for me. The recorder (Test Builder) behaved sporadically when dealing withe Chrome's authentication dialog. Most of the time Test Builder is either hanging or unresponsive. On the times that it does record, the recorded code is just some keyboard.sendkeys calls that wouldn't even playback properly. I cannot inspect the edit boxes to get their properties either; Test Builder will just hang.
I got by with manually coding combination of Keyboard.SendKeys() to fill in user name and passwords, then finding the Log In button and clicking on it. I don't think that's a reliable approach though.
If you have any other suggestion please do share. Thanks.
Yes I could repro the weird behavior at our end and am investigating the issue.
Just a parallel question, I assume these credentials are different from your logged in credentials?
If it's the same you can probably make use of Windows auto logon [Enabled by default I believe or you can change it from Chrome Advanced Settings -> Proxy Settings -> Security --> Custom Level)
If you have further queries you can send an email to SKHAN AT MICROSOFT DOT COM
I am glad that you can reproduce the problem and is investigating it.
Yes, I am using different credentials to log on, so single sign on will not work for me.
I am using Coded UI to test a ASP.NET web application in IE 8. This app also requires authentication through the Windows Security dialog. I am able to enter my credentials through Coded UI, but once this is done, the Coded UI scripts have trouble finding controls in the underlying IE window. This doesn't always happen...probably about half the time. Any suggestions?
Please disregard my post above. It turns out the problem was not related to the Windows Security dialog at all.
With Visual Studio Update 2, and the latest Cross Browser MSI, users may sometimes hit the issue where Chrome initially always launches the First Time Run dialog.
Please refer blogs.msdn.com/.../handling-browser-profile-issues-while-doing-cross-browser-testing-with-coded-ui-test.aspx
and set your chrome profile directory, to ensure your default is always picked up on chrome.