UI Automation Not Fit for Command!

kick it on DotNetKicks.com
I have been spending a lot of time exploring automation testing frameworks that can be driven using NUnit. I am exploring the following:

I am finding that the "Roll Your Own" method is the most versatile method. I will write about this method later. Today, I feel like a more negative tone. I will say it now:

Microsoft’s UI Automation Framework is NOT fit for command.

Don’t get me wrong… there are a lot of easy-to-use systems in .NET. BUT, I find the Code DOM easier to use than the UI Automation tools. If you have ever used the Code DOM, you know that I am saying a lot with this.

Here are my issues with the UI Automation Framework:

  • UI Spy Doesn’t Ship with Visual Studio 2008. If you want UI Spy, you need to download the SDK for Windows Vista. Don’t try to use this framework without it. You will fail.
  • The UI Spy tool is buggy and crashy and slow. Did I mention that this tool is essential?
  • As much as I research it, I can’t figure out how to do the first two things I tried to do: Click on a LinkLabel and enter text into a RichTextBox. I know how to click on a button and enter text into a TextBox, but the more complicated versions of this are too difficult, aparently.
  • The API is terribly difficult to write AND read. Not intuitive at all!
  • Finding controls using the NameProperty doesn’t use the "Name" property. It uses the "Text" property. If you want to search for a control using the "Name" property, you need to use AutomationIdProperty. Did I mention that the API is awful? This is why you need the UI Spy tool.
  • The framework itself is slow
  • You need a separate thread to catch modal dialogs. Have you ever tried to write tests that utilize multiple threads?

These are the problems I have run into with just a few hours of use. I need to mention that NUnit Forms, Ranorex and "Roll Your Own" tests were all easier to write/read/execute with the same level of effort.

Leave a Reply