Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
Visual Studio has a variety of ways to test your code. – one of them we call “Coded UI”. Coded UI testing is useful when you want to automate a full functional test, as a user would do it, against the UI of your application. You usually start by recording a test case – you manually execute the test in the app and the recorder watches what you do. You also define as set of things you want to verify about the result. It turns your actions into a sequence of events to send to controls in your application. It can generate code for that sequence of events and you can then tweak that code if you like.
In order to do this, the Coded UI tools have to be able to reach into your app and automate actions against its various components. As a general rule, doing that at the top level – key strokes and mouse clicks is a bad idea because it makes the test too fragile and too difficult to maintain. Those lower level events are turned into application level actions – button pushes, list selection, etc. In order to do that, your app must expose the structure/behavior of its controls in a way that can be automated. Of course, we’ve made sure it works for all the built in controls but what about custom controls or 3rd party controls?
We need to understand them. To enable that we support automating using Microsoft Active Accessibility (MSAA) which is the same interface screen readers and the like use to help people with disabilities use software. The advantage of doing it that way is that a control implementer can, in one fell swoop, make their controls both accessible and testable – a double benefit.
MSAA gives you a basic level of testability but you can go further – enabling validation, composition of lower-level actions into logical actions, etc. And the more you do, the richer your testing support can be. For automating tests on custom controls, one can follow the below ladder to add Coded UI support as described in the blog http://blogs.msdn.com/b/visualstudioalm/archive/2011/10/28/coded-ui-test-extension-for-3rd-party-controls-the-basics-explained.aspx. The graphic here shows a path from no support to rich testing support with Coded UI tests.
We are glad to announce that DevExpress is the first 3rd party control vendor to have gone past implementing MSAA and have enabled all the above scenarios. One can start recording actions on a DXperience 12.1 WinForms control using Coded UI Test Builder and play them back using Coded UI Test. These controls also expose meaningful rich properties that could be used for functional validation during automation test, for example, validate the control specific property RowIndex on a XtraPivotGrid control. DevExpress has also added rich APIs to ease authoring of Coded UI Tests on custom controls. Last but not the least, conversion of sequence of actions into meaningful intent has been made possible through the aggregation filters, for example, navigation through filter tree to set filter condition on a grid is now converted to one composite action which sets the filter value.
You should check out the DevExpress controls.