Coded UI Test- Extensibility VS2013 Update2

  • Article

Irfan Ahmed, Senior Support Escalation Engineer, brings this amazing write up on Coded UI Test-Extensibility. Read on!!

In this blog, we are going to talk about some changes in Coded UI extension (CUIT) classes in Vs2013 Update 2.  In VS2013 Update 2 we enhanced the Coded UI Test extensibility model to support plugins built for Windowless controls including controls in Modern Apps.

In case you are new to CUIT extension, we strongly suggest you go through the following series of blogs to understand the basic and advance topics regarding coded UI extension before you read this blog. 

This blog will be helpful if you find that your CUIT extension is not working and more specifically failed to find the control/element in the application. 

Why and what change?  

The main reason of making these changes was basically on two aspects. One to enable CodedUI testing for Windows Store Apps and Second was to make it more robust in working with existing wide range of controls.   

A new set of extensibility API’s have been exposed by CUIT to deal with usage of an AutomationElement as a parameter instead of window handle when querying a plugin for support. This would enable plugin writers to provide support primarily for Windowless controls and   ease in the support for extending control specific support 

In VS2013 , we have a class called UITechnologyManagerProxy.  Extension plugins are recommended to override this and customize their technology manager behavior. This is an abstract class.   

This class UITechnologyManagerProxy provides a couple of new methods explained below. 

  

  • ConvertToExtensionElement 
  • GetControlSupportLevel ( System.Windows.Automation.AutomationElement element)  

ConvertToExtensionElement 

  This method is used to convert core element to extension element.

  All plugins extending this proxy technology manager must implement this and create a simple conversion with copy of core technology element and extension manager. 

  

Example from one of my CUIT extension code 

 public override IUITechnologyElement ConvertToExtensionElement(IUITechnologyElement coreElement) 

       
{             

       
if (coreElement.ControlTypeName.Equals("Header")
&& coreElement.Name.Equals("View")) 

          
{ 

               
return new RibbonTabHeader(coreElement);   // RibbonTabHeader is my class which is
inherited from UITechnologyElementProxy 

         
}                

             
return coreElement; 

       
} 

   

 public override IUITechnologyElement ConvertToExtensionElement(IUITechnologyElement coreElement)  

{ 

 ExtensionTechnologyElement extensionElement = new ExtensionTechnologyElement(); 

 extensionElement.ExtensionTechnologyManager = this; 

 extensionElement.CoreTechnologyElement = coreElement;  

 return extensionElement; 

 } 

  

Note:   ConvertToExtensionElement is used to convert the given element of another technology to new element of this technology manager. This is used for operations such as switching between hosted and hosting technologies 

  

GetControlSupportLevel ( AutomationElement element)  

We have added this new override method in UITechnologyManagerProxy class. This method takes AutomationElement as a parameter. This gives us more details about element which you want  CUIT framework to recognize.  In other override of GetControlSupportLevel, we take a IntPtr Window Handle and get the class Name from it to identify the control.  

Though GetControlSupportLevel (intPtr) was working fine in most of the cases, we came across scenarios where it fails to get right support level filled up. Adding a support for AutomationElement makes the method more robust.  With WindowHandle as a parameter, Windowless control specific support was not possible and that’s where AutomationElement helps identify such windowless controls.