Experiences with UI Automation and WPF

Question

We are developing a rather large WPF based application and would like to include some automated UI testing in our test suite (which already contains a number of unit tests).

The UI Automation Framework from Microsoft partly sounds like a perfect fit for programatically launching and interacting with the application in a test setup. However, I've struggled to find solid references for samples and experiences with the technology, the articles and small samples available on MSDN is not enough to convince me that it is a solid choice.

So, does anybody have real world experiences using the UI Automation Framework in their test suite? What are the caveats and the gotchas? Any best practices when written tests scripts, can you "record and replay" to a scriptable format, how much should you facilitate the testing from the application, how did you incorporate it in the automatic build? Should we be looking in another direction than the UI Automation Framework?

Feel free to post you experiences here or link to some good references I might have missed

Answer 1

Where i work we have just started to evaluate some test tools for our system. We came across a tool called white, which uses the UI Automation Framework. Check here for more information on it. Note that white does also have a record function although i think it has looks of issues and is still being developed. What we tried doing was set them up to look like unit tests i.e. [TestFixture] [Test] etc. then we were able to run them through nunit at the same time as the unit tests.

We have found that it can be difficult to access some of the components within your window, but haven't had much of a chance to investigate why.

If you don't mind paying for the software then I would recommend Test Complete.

Answer 2

Hi, I'm in the middle of doing the UI Automation of a WPF app at work. I'm using White and IronRuby and it works great. I've written up how I've done it here: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

We initially went with white, and then moved away from it. It tries to be generic and abstract over the Win32 API, Winforms, Java apps, and the MS UI automation API. The MS UI automation API is also trying to be generic and abstract over the win32 api and winforms and WPF, so you end up in a "lowest-common-denominator-of-lowest-common-denominator" scenario.

The result of this was that the White element searching API simply wasn't flexible enough to find various UI elements that we needed to find, and it didn't expose enough of the underlying UI automation framework elements for us to do anything useful with it.

We ended up going with a homegrown sort-of-framework; We use the MS UIAutomation framework directly, but have extension methods and helper classes to deal with the scenarios it doesn't address. (Keyboard and Mouse input, primarily).

Note: our test scripts and homegrown framework are all using IronRuby. Ruby's ability to add methods to existing classes and it's flexible syntax (combined with method_missing) are awesome for this kind of thing.