Some important notes before I talk about the utility –
- This posting, and the sample herewith, are provided "AS IS" with no warranties, and confers no rights.
- Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
- The sample is not supported by Microsoft or the author of this blog. If you have suggestion\feedback\issue with the sample, you may leave comment on this blog and the author will get back to you in his next free cycles.
The attached sample utility adds support for XPath query to Coded UI Test for searching controls. The utility uses built-in XPath parser and other classes of .NET and as such is conformant to .NET’s XPath Syntax. The new utility assembly adds two extension methods to UITestControl class –
To use these methods, unzip the attached sample and add reference in your Coded UI Test project to the UITestXPathUtility.dll. (Note that you have manually ensure this dll is there on all machines on which the tests are run.)
Some examples of how to use these functions are –
XPath is very powerful and expressive – I have not tested for all syntax but the way implementation is I believe all syntax would be supported. In implementation, I am not parsing or doing anything specific to XPath grammar but rather providing navigation capability via XPathNavigator interface to standard .NET APIs to support XPath.
Before using the sample further, note the two limitations\issues here –
- Semantic difference – The Coded UI Test’s built in search does a breadth-first search whereas this utility (due to implementation of standard XPath) does depth-first search. This means in certain cases, the result between the two could be different.
- Perf issue – Because this is layer on top of UITestControl and does not uses any technology specific intelligence to speed up the search, the performance is slower than the built in search. The exact difference depends on the query and depth of the tree. For example, for if the control under which you are searching has deep control hierarchy within it, the search performance could even be 10x slower. On the other hand, say the control under which you are searching is just one or two level deep and query is simple enough, there will be hardly any impact.
Because of the above two limitations\issues, this should not be used as a widespread replacement of the built-in search. You should use it with prudence at places where you really need ease of use and power of XPath. I would suggest limiting the usage to places where control tree is not deep to overcome the performance penalty.