Bringing you news, technical articles, and other useful content about Visual Studio ALM and Team Foundation Server
More videos »
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
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
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
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
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
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
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
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
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.
Is there a way to do this for third party WEB controls?
This is a good start. Thanks! Does "validation of basic control properties" in level one mean you can do assertions on them? I apologize, but am not an expert developer: what's the difference between basic control properties and custom properties?
Yes, you can perform assertions/validations on basic control-specific and generic properties exposed through Coded UI MSAA plugin for WinForms.
However, if there are more control-specific proprties that one wants to assert on, they would have to add level 2 implementation.
I am not sure if I missed something here, but I don't feel like much of the basics(or any really) of how to extend CUIT to 3rd party controls was explained here. You stated what the "extensibility ladder" was but do you have any detail on how to go about implementing each of these steps? You touch on how it can be done in a step-by-step manner but would you be able to expand on what that means?
yes I agree with J, need more direction