Coded UI Test Extension for 3rd party controls - the basics explained

Having developed a 3rd party control, wonder what it takes to go from NO support to FULL support for Coded UI Test? How to make the UI elements testable by Coded UI Test – to be able to create automated tests from manual recording, record user actions, generate code from user actions, add custom code to UI Tests and finally run those coded UI Tests?

Well it could be accomplished by step-by-step implementation with each step allowing access to rich features of Coded UI Test as shown below. All of this can be accomplished by leveraging the extension points of Coded UI Test framework.

Fig 1: Shows four steps needed to get from NO support to FULL Coded UI support

Level 1: Basic Record and Playback

Without

1. Recorder records co-ordinate clicks and does not recognize element in the UI hierarchy. As a result, tests would fail when application window is resized or when control is not in view during test run

2. Validation tests on control properties is not possible as recorder does not recognize the element object

 With

1. Recorder records co-ordinate click, sends a request to Technology Abstraction Layer (TAL) to identify the element from co-ordinate point. TAL retrieves element information from the appropriate plugin depending upon control support level and returns the element information to the recorder

2. Navigation possible amongst siblings or parents or children

3. Validation of basic control properties are now possible

4. Can extend control code to get to Level 1; no plugins required

Fig 2: Shows that Coded UI Test Builder crosshair identifies a cell inside a GridView and exposes basic cell properties if Level 1 is implemented

Level 2: Rich Property Validation

Without

1. User not able to add assertion on custom properties of controls

2. Playback engine would not be able to validate custom properties of controls during test run

 With

1. User can add assertion on custom properties

2. Playback engine validates properties during test run

3. Extend PropertyProvider and add plugin

Fig 3: Shows how custom properties such as BackColor/ForeColor/BorderColor of Cell can be exposed through extension thus enabling assertion if Level 2 is implemented

Level 3: Code Generation

Without

1. Objects and properties of auto-generated test code are derived from the base class of UI Test framework – UITestControl 

Fig 4: Shows that auto-generated code on cell click is registered on default cell object - WinCell

With

1. Specialized classes can be written for each control

2. Auto-generated test code is more readable and maintainable

3. Extend PropertyProvider and add plugin 

Fig 5: Shows that auto-generated code on a Cell click is registered on custom object – GridViewCellInfo if Level 3 is implemented

Level 4: Intent Aware Actions

Without

1. Recorder records all mouse clicks and keyboard inputs

2. Recordings not linked to control behavior

3. E.g. Set “Tom Scott” in table cell recorded as Click Cell –> Click Cell (to enable editing) –> Edit Text on edit box although the extra click is not relevant and final intent is to set cell value instead of text box 

Fig 6: Set “Tom Scott” in table cell recorded as Click Cell –> Click Cell (to enable editing) –> Type “Tom Scott” in text box

With

1. Recorder aggregates actions on action stack based on filter rules in Action Filter

2. Can record only intended steps based on control behavior

3. E.g. Set “Tom Scott” in table cell recorded as Click Cell –> Type “Tom Scott” on cell

4. Extend ActionFilter and add plugin 

Fig 7: Set “Tom Scott” in table cell recorded as Click Cell –> Type “Tom Scott” on cell if Level 4 is implemented

Having added implementation for all the above levels, a control developer can claim FULL Coded UI Support. However, most Coded UI Test features could be used just by implementing Level 1.