Microsoft UI Automation Library Vs Coded UI Test

I'm very much new to Test Automation kind of thing. Recently I've been assigned to a project where I have to write an application (or, a script may be, I'm not sure) that will automate the UI testing of a CAD-like WPF application which misses lots of AutomationIds.

After doing a little searchin开发者_运维百科g on MSDN and other sources I'm a bit confused about whether I should use the Microsoft UI Automation Library or the new Coded UI Test feature included in VS2010. I'm not getting the clear picture of which one of these two applies in which scenarios, what advantages one has over the other and which one suits my purpose.

Please shade some light if you have experience/knowledge on the matter. Thanks in advance.

Basically Microsoft UIA is the new accesibility library in .Net 4.0. WPF applications and controls have built-in support for UIA through the AutomationPeer class.

Coded-UI test is a Record & Play automation tool which uses the Microsoft UIA Library underneath. Since being a tool compared to writing code in C# it improves QA productivity for recording more test cases.

For applications with automation support planned into it, Coded-Ui should be sufficient. If the AutomationIDs are missing make sure the controls have some unique property like Name. Use UIVerify or Inspect to check for this.

If NO unique property is avialble, there are the other below mentioned techniques you can use in combination with Coded-UI.

• From an Event When your application receives a UI Automation event, the source object passed to your event handler is an AutomationElement. For example, if you have subscribed to focus-changed events, the source passed to your AutomationFocusChangedEventHandler is the element that received the focus. For more information, see Subscribe to UI Automation Events.

• From a Point: If you have screen coordinates (for example, a cursor position), you can retrieve an AutomationElement by using the static FromPoint method.

• From a Window Handle: To retrieve an AutomationElement from an HWND, use the static FromHandle method.

• From the Focused Control: You can retrieve an AutomationElement that represents the focused control from the static FocusedElement property.

If you can leverage and use the Coded UI Test then go that route. Make sure to verify that your given configuration is supported.

The UI Automation Library resolves everything in the code behind. This then forces you to use a tool like UISpy to gain access to the controls internals so that you can then build out your test.

A Coded UI Test on the other hand still has code behind however it allows for the recording of steps through the given application which you are testing which will greatly increase the number of tests you can create.

UI Automation library is a low-level library. Usually, you don't want to write tests against it directly as it requires a pretty decent amount of work.

I would recommend looking at more high-level libraries. You mentioned one of them - Coded UI; another good choice would be White from TestStack. They both suits different kinds of projects. Coded UI is good when you don't want to invest a lot of efforts into your test suite. At the same time, it doesn't scale much so if you are going to write a lot of tests, you are better of choosing White.

Here I compare the two frameworks in more detail: Coded UI vs White

To complement the above responses, please look at CUITE that helps quite a bit and may be an appropriate approach for you.

I began 'rolling-my-own' 'semi-framework' using the CodedUITest library and devised a paradigm for separating the details of automation from the (C#) code. Basically, I am creating a driver that reads what needs to be done from spreadsheet(s) where each line in it is a test step (or a pointer to a scenario in a different worksheet). At present, incomplete, but promising, I have it working against a WPF application with partial success. One of the main problems is that the developers neglected to identify controls uniquely and consistently.

Bey