CODEWITHSUNDEEP
c#user-interfaceautomationcoded-ui-tests
user2917239
user2917239

Reputation: 898

Why does Coded UI not recognize certain controls?

On web applications, I have noticed that there are certain types of controls that Coded UI does not capture in the same way as normal html controls, which inhibits my ability to data-drive those elements.

Some examples of these controls are Telerik Ajax controls and also Ideal Forms, which is a js framework similar to bootstrap.

What are the reasons that cause this incompatibility between Coded UI and these types of controls? Is there any work around it other than replacing the controls of the application?

Upvotes: 3

Views: 2698

Answers (3)

AdrianHHH
AdrianHHH

Reputation: 14086

Coded UI accesses applications using the MSAA (Microsoft Active Accessibility) or UIA (UI Automation) interfaces. These interface were originally provided to allow programs like screen readers for sight impaired people or for other forms of keyboards and mouse for people with dexterity problems. Coded UI uses these interfaces and drives applications in the same manner that these programs would drive an application.

The UI controls of an application must be written to support either MSAA or UIA. Almost all of the recent Microsoft controls support these interfaces, there is limited support in the older interfaces such as MFC and Win32. Custom controls are not supported unless the MSAA or UIA interface are implemented. Some third party custom controls do not support these interfaces. Check their support pages and see what level of Coded UI support the different revisions support.

Recent versions of many third controls do support Coded UI.

Upvotes: 2

yonitdm
yonitdm

Reputation: 441

As the previous answers have covered the why, I'll focus on the "now what?"

We have employed various work arounds to handle inscrutable controls.

  • screen points: one application presented a form that coded ui sees as a blank window. we resize the application during test to ensure consistent placement and use screen points. This has the highest maintenance, the least adherence to good testing practices, down n dirty hack.
  • keyboard shortcuts- for traversing a list/dropdown that coded ui cannot see we click on the object using one of our other hacks, then use down keys to navigate based on a struct, enum or xml of the structure. Easy enough to update them when the options change location/order
  • sikuli - the most sound, yet sometimes the most tricky to use is image verification. We take a screen shot of the control and use sikuli code to interact with the object by calling the sikuli script from inside coded ui. Because this is outside of coded ui, the logging isn't included automatically. The false positives and false negatives can be worked around most of the time.
  • avoidance - if we can't verify the content in a control coded ui can't see, we'll report back that that section is not an automation candidate and will need to be checked manually

Upvotes: 2

Ryan Butler
Ryan Butler

Reputation: 13

Microsoft Coded UI doesn't support Telerik controls last I knew. Coded UI doesn't work correctly on many third-party controls (Telerik, Infragistics, etc). The only choice is changing the controls to be more native, or use a different automation test tool, such as HP Quick Test Professional or Telerik, etc.

Upvotes: 1

Related Questions