June | 2011 | nf2p.com

Introduction

Creating automated acceptance tests for a Windows application can be a daunting task, especially if you’re not familiar with the Windows UI Automation API. Add to that the fact that your window will usually be running on a thread seperate to your tests (it certainly will if you use the code in this post), and you have a recipe for some horrible looking test code. However, you can hide away some of the horribleness if you can identify common tasks and model them as operations in functions or classes.

Operation 1 is starting up your window and obtaining a reference to it. Unfortunately, doing so for a WPF Window is a little trickier than it at first seems. However, I’ve coded up a couple of classes that may be of use for people getting started in this area.

UiOperation

First up is UiOperation. This class basically uses a few delegates and timeout values in order to try to perform an operation over and over until it’s either successful, or it times out. The class is fairly generic, so its purpose it not at first obvious and perhaps requires some explanation.

Imagine loading a window on another thread. You start the loading of the window, and at some point in the future it will appear. You basically want to keep trying to get a reference to that window for a while. If the window doesn’t appear after a while, then you timeout and fail. This class encapsulates that try, try, try, fail behaviour in a verstaile way which can be applied to a myriad of UI operations.

public class UiOperation<T>
{
private const Int32 OPERATION_TIMEOUT = 5000;
private const Int32 OPERATION_RETRY_DELAY = 150;
private readonly Int32 operationTimeout;
private readonly Int32 retryDelay;
private readonly T initialValue;
private readonly Func<T> getValue;
private readonly Func<T, Boolean> successCondition;
public UiOperation(Func<T> getValue)
: this(default(T), getValue, v => v != null && !v.Equals(default(T))) { }
public UiOperation(T initialValue, Func<T> getValue,
Func<T, Boolean> successCondition)
: this(initialValue, getValue, successCondition,
OPERATION_TIMEOUT, OPERATION_RETRY_DELAY) { }
public UiOperation(T initialValue, Func<T> getValue,
Func<T, Boolean> successCondition,
Int32 operationTimeout, Int32 retryDelay)
{
if (getValue == null)
{
throw new ArgumentNullException("getValue");
}
if (successCondition == null)
{
throw new ArgumentNullException("successCondition");
}
this.initialValue = initialValue;
this.getValue = getValue;
this.successCondition = successCondition;
this.operationTimeout = operationTimeout;
this.retryDelay = retryDelay;
}
public T Invoke()
{
var value = initialValue;
var started = DateTime.Now;
do
{
value = getValue();
if (successCondition(value))
{
break;
}
Thread.Sleep(retryDelay);
} while ((DateTime.Now – started).TotalMilliseconds <= operationTimeout);
return value;
}
}

WindowRunner

WindowRunner is where we kick off a new window in a seperate AppDomain. Now, you can just kick off another thread to run the window without the new AppDomain, but if you’re using DataTemplates and coding using MVVM, you may find your templates aren’t loaded. In addition, running in a seperate AppDomain keeps failures nicely isolated so any in memory state shouldn’t persist between tests, and it’s closer to how your users will run your application.

public class WindowRunner
{
private const Int32 WINDOW_STARTUP_TIMEOUT = 15000;
private readonly String windowAutomationId;
private readonly Type windowType;
public WindowRunner(Type windowType, String windowAutomationId)
{
if (windowType == null)
{
throw new ArgumentNullException("windowType");
}
if (windowAutomationId == null)
{
throw new ArgumentNullException("windowAutomationId");
}
this.windowType = windowType;
this.windowAutomationId = windowAutomationId;
}
public AutomationElement Start(params String[] arguments)
{
RunWindowAsync(arguments);
var windowElement = TryGetWindowElement();
if (windowElement == null)
{
throw new TimeoutException(
"Could not load application and find " + windowAutomationId +
" within " + WINDOW_STARTUP_TIMEOUT + "ms");
}
return windowElement;
}
private AutomationElement TryGetWindowElement()
{
var desktop = AutomationElement.RootElement;
var condition = new PropertyCondition(AutomationElement.AutomationIdProperty,
windowAutomationId);
var getWindowElementOperation = new UiOperation<AutomationElement>(
null,
() => desktop.FindFirst(TreeScope.Children, condition),
e => e != null,
WINDOW_STARTUP_TIMEOUT,
150);
return getWindowElementOperation.Invoke();
}
private void RunWindowAsync(params String[] arguments)
{
var thread = new Thread(() =>
{
var domain = AppDomain.CreateDomain("WindowRunnerDomain");
var assembly = Assembly.GetAssembly(windowType);
domain.ExecuteAssemblyByName(assembly.GetName(), arguments);
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
}
}

Here, we just use the type of the window to find the assembly to execute in our new AppDomain. We use the automation ID to find the window (the window’s Name property in WPF, which you need to set).

Trickiness with Receiving Command Line Arguments from WindowRunner

If you’re like me, and have added command line arguments to your WPF application, you’ll have to engage in a little friggery pokery in your WPF application so that you can implement your own static void Main(String[] args) and access the arguments passed in via AppDomain.ExecuteAssemblyByName in WindowRunner. This isn’t too difficult though:

Stick a new Main declaration in App.xaml.cs
Set App.xaml’s build action property to ‘Page’

This will prevent MSBuild from creating a default Main in the App class, and gives you direct control.

A Sample Test

A typical test would start like so, with some database connection details passed as command line arguments.

[Test]
public void WhenMyApplicationIsStartedICanSeeTheMainWindow()
{
var windowRunner = new WindowRunner(typeof(MainWindow), "AlexApplicationWindow");
var windowElement = windowRunner.Start(TestConstants.ConnectionString);
}

That test simply executes the assembly that MainWindow is contained in, and waits to find a desktop child named AlexApplicationWindow (for this to work I need to set Name=”AlexApplicationWindow” on the Window element in MainWindow.xaml). If the window appears within about 15 seconds, all is good. If not, a TimeoutException is thrown.

All my acceptance tests start like this, with each drilling down into the control hierarchy and invoking different controls to carry out use cases and check that we get the expected results.

Conclusion

Once you have your window’s AutomationElement, navigating and finding other important elements in your control hierarchy to interact with takes a fair bit of patience (you must try the Inspect Objects tool shipped with the Windows SDK – it will save you hours), but it’s worth it. As long as you keep on factoring the code so that common operations are nicely tucked away and easily invokable you can form a clean and comprehensive library of acceptance tests.

Share and Enjoy: