In June 2011 we released an hot fix (KB2544407) addressing several issues that our customers are facing while using testing tools in Visual Studio 2010 Service Pack1. In that list one was related to Coded UI testing for WPF controls that are deep in hierachy. Following is the detailed information about the issue and how it is being fixed by the hot fix.
Some important links:
Brief information of all the issues fixed in the hotfix can be found here.
Download link for the hotfix can be found here.
In WPF a control may be present under a different control at any nested level. In Coded UI Test we look for 2 levels up from control’s immediate ancestor [parent of the control in Coded UI Test] to see if there is any container control [e.g., Tab, ListBox, DataGrid]. If we don’t find it within 2 levels, no container control will be included in the Query ID. This will be an issue during playback, as we do not search inside a container control if it is not part of the Query ID for performance reasons. So if a container control exists above 2 or more levels from the control user acted on, playback will fail to find that control. The reason for going only 2 levels up to find the container control during recording is to void the performance impact and this number is chosen based on the testing done on real world applications scenarios. But we have been seeing going up to 2 levels is not sufficient some time. User may have some control which is nested at more than 2 levels deep under a container control.
What is the fix:
So to fix this, we have exposed a configuration key named ‘MaxLevelsForItemContainer” so that user can define the maximum level he is interested to look for an item container control in WPF applications. User can define this key in CodedUITestBuilder.exe.config/MTM.exe.config file as shown below. If the following key does not exist the default value still be 2 only.
<add key=”MaxLevelsForItemContainer” value=”<desiredLevel>”/>
How a user can figure out the no of levels:
In the sample application provided in this article, the hierarchy for the check box controls present inside the group items will be like as follows
UI hierarchy [using UISpy tool]
The container control [tab] is 3 levels up from the parent [group ‘flower1’] of the check box. If you try to record actions on the checkbox or create an assertion for the properties of checkbox control, following will be the hierarchy in Coded UI Test [picked up from Coded UI Test builder].
So it is clear from the above hierarchy that CheckBox control’s hierarchy does not have information related to tab item and tab control hence it is bound to fail when user runs the through Coded UI Test or Microsoft Test Manager.
Reason being while generating the hierarchy for the checkbox control, the recorder looks up to 2 levels from checkbox’s parent i.e., UIFlower1Group and hence no container control is found it comes out and the above hierarchy is generated.
To fix the above issue, user first should try to find the max no of levels recorder should look up for container control using UISpy tool, in this case it is 3 [Flower1 (group)=> Flowers (group) => OnlineStore (TabItem) => Tab], and then update the
CodedUITestBuilder.exe.config or MTM.exe.config based on user’s need. A sample config file for CodedUITestBuilder.exe is attached within this article.
Following key should be added in config file under <appsettings> node.
<add key=”MaxLevelsForItemContainer” value=”3″/>
Once the above is done, restart the CodedUITestBuilder and do the same action again on checkbox. This time user can see the complete hierarchy present for the control as shown below.
I have attached the sample configuration file for Coded UI Test builder and a sample application to reproduce the issue mentioned in the blog post. Users can use them to understand it better.
To understand more about WPF plugin in Visual Studio 2010 AFN and property validation refer the following deep dive sections on WPF support: