I’ve recently done some research into .NET WinForms testing on behalf of a customer and there are several different levels which we can attack this. Each is of different complexity and cost.
Simulate Mouse Clicks and Keyboard Presses
This method has been around since Windows 3.1 days and involves heavy use of SendKeys and SendMessage to manipulate Window message queue to send mouse and keyboard events directly. An old but pretty good sample is at http://msdn.microsoft.com/msdnmag/issues/02/03/Bugslayer/.
Drive Forms Controls Directly
The next simplest method is to get hold of Windows forms controls directly so you can call methods and set properties using code. This method usually involves running the target forms within your own process. The following two MSDN magazine articles describe the steps:
The second one looks at how to cancel message boxes etc by sending messages directly to the window. Both articles describe the method but they are not very user friendly and you will have to write a fair amount of code. Fortunately there is a library available that hooks into the NUnit testing framework at http://nunitforms.sourceforge.net/. Still lots of code but you get to write higher level stuff such as:
ButtonTester button = new ButtonTester("nameOfSomeButton");
button.Click();
Assert.Equals(“Clicked!”, button.Text);
The only problem I can see with this is maybe development has stopped as the last full release was in November 2004 with a few alphas up until May 2006. Still you can grab the source and start hacking away if there are any problems.
Using Active Accessibility 2.0
This API has been around for a few years and is a standard way of controlling all Windows controls. The trouble is though that it’s a COM API and somewhat complex to master. I’ve seen anecdotes on the Internet talking about the test code being more complex than the application code when using this. For completeness the API is documented at http://msdn2.microsoft.com/en-us/library/ms697707.aspx though the following section has a more modern way of doing this. A walkthrough is available showing how to make a .NET application accessible at http://msdn2.microsoft.com/en-us/library/cb35a5fw(vs.80).aspx.
Using UI Automation
UI Automation is the successor to Active Accessibility and, unlike Active Accessibility, was specifically designed with automation in mind. It’s described in more detail at http://msdn2.microsoft.com/en-us/library/aa348551.aspx with a complete walkthrough and sample code at http://msdn.microsoft.com/msdnmag/issues/07/03/Bugslayer/default.aspx. One thing to note though – the UI Automation bits are only available on computers with .NET 3.0 installed – i.e. Vista, Windows XP and Windows Server 2003.
There is also a very useful library available to help with the code at http://www.codeplex.com/uapp.
Third Party Tools
This wouldn’t be complete without a nod to some of the commercial offerings out there. I haven’t used any since Rational Test many years ago which was next to useless but I hear reasonably good things about Mercury QuickTest Professional though I have no idea how much it costs. There is even a virtual lab available on Automating Testing of Windows Forms Application with TestComplete and Visual Studio 2005 Team System.
Conclusions
To summarize, I would recommend trying NUnitForms and UI Automation to see how you get on with both of them and making a choice between the two. QuickTest Professional will probably be too costly and the other two technologies are a lot of work and too old to consider for all your testing – they may have tactical uses though.