Thibaut Barrère / LoGeek

Yesterday I started adding test to a windows form application. Until now I only tested non graphic libraries, but was concerned about how to lock the behavior of a graphic application. Graphic applications (both web and non-web) are usually very likely to regress from a functional point of view, and seem to generate a lot of support ("Didn't you fix that already ?"), maybe because an inspired gui tester has that kind of black magic skills to find new, undiscovered ways to use your application ("This *cannot* happen!! How did you do that?")

Anyway. I started small - a few tests, with a small application.

For regular (non graphic) tests, I used classic NUnit tests. And when I started testing forms, I checked out NUnitForms, which is an "NUnit extension for unit and acceptance testing of Windows Forms applications".

Setting up

For a practical point of view, when testing libraries I usually create a separate test project, and most of the time unit test the public parts of the tested assemblies which are located in other projects in the solution.

But this time, at least under VS.Net 2003 this won't work : I can't reference an "application project" assembly from another project (although it is allowed by the c# compiler itself, the IDE is not letting us do it).

So I decided to put the tests inside the application, in a separate Tests sub-namespace. This way I can cope with the IDE limitation, plus avoid the visibility issues.

There's plenty of other ways to do that of course (and debates around it as well), but that's not the purpose of this post.

To finish the setup, I just added nunit.framework.dll and NUnitForms.dll to the application assembly references.

Writing a test

Apart from usual NUnit test I wrote for the same application, I wanted to start testing a form. This form is called ErrorReportingForm, has a LinkLabel called _close which should manage to close the form, and an ErrorText property which value should be dumped into a TextBox called _errorMessage, along with other informations (including the list of assemblies in current appdomain).

Here's the test code first :

using System;
using NUnit.Framework;
using NUnit.Extensions.Forms;

using DotNetGuru.Examples.Forms;

namespace DotNetGuru.Examples.Forms.Tests
{
    [TestFixture]
    public class ErrorReportingFormTest
    {
        bool hasClosed=false;
        private void form_Closed(object sender,EventArgs args)
        {
            hasClosed=true;
        }

        [Test]
        public void CloseForm()
        {
            ErrorReportingForm form = new ErrorReportingForm();
            form.Closed+=new EventHandler(form_Closed);
            form.Show();
            
            LinkLabelTester ctrl = new LinkLabelTester("_close",form);
            ctrl.Click();
            Assert.IsTrue(hasClosed);
        }

        [Test]
        public void TextBoxShouldContainMessage()
        {
            ErrorReportingForm form = new ErrorReportingForm();
            form.ErrorText="This is the error I want to display";
            form.Show();
            
            TextBoxTester ctrl = new TextBoxTester("_errorMessage",form);
            Assert.IsTrue(ctrl.Text.IndexOf("This is the error I want to display")!=-1);
        }
    }
}

First thing is there's no breaking change with NUnit, only extensions. I have to import the NUnit.Extensions.Forms namespace in addition to NUnit.Framework. Then I declare my TestFixture and Test as usual.

I wanted to ensure the close button really close the windows. What's the need for that ? I just want to detect if no exception is thrown, for instance.

With NUnitForms I just instanciate the form. To be informed that the form has closed I hook up the Closed event. Then I call Show(), which causes NUnitForms to open the form in a separate, hidden desktop.

Then I use the NUnitForms tester objects to simulate actions on the control named "_close", then check that my callback has been called.

NUnitForms (now 1.3.1) provides support for a part of the Windows Forms (including "Buttons, CheckBoxes, ComboBoxes, Labels, ListBoxes, RadioButtons, TabControls, TextBoxes, TreeViews, Context Menus, Forms, MenuItems, Modal Forms, Modal MessageBoxes, and the Mouse", the list is growing), and still leave you with the opportunity to use a generic ControlTester class if the control you want to test is not yet supported (or not at all).

I should also mention that it comes bundled with a Recorder application with confused me a bit first (you have to select which form you want to test in the dropdown list), but which is handy once you have it working: it let you interact with the form and record what's happening (in term of real, typed events, not (x;y) click coordinates like other test recording tools). You just have to copy and paste the generated code into your test project to start testing.

Running and debugging tests with TestDriven.Net

For those who don't know it yet, TestDriven.Net is a VS.NET add-in to allow running and debugging unit tests in a very comfortable way. The latest release can be found here.

The good news is : it works perfect with NUnitForms so far!

Just like any other NUnit test, I can run a NUnitForms test, debug it step-by-step, put breakpoints etc. Isn't that sweet ?

The build process

Just as seamless, my CruiseControl.Net + NAnt setup accepted the NUnitForms tests and properly executed them.

Time to leave

It is actually simpler than what I expected to *start* testing graphical user interfaces, and now the tools under .Net are getting very well integrated to achieve that.

There are a lot more questions on how to test more complex things (just like for classical nunit tests when it comes to database testing, distributed testing, nmock etc), but at least the beginning is promising and I'll explore more.

Edit (25/11/2004) : Jose Almeida has blogged about another way to setup NUnitForms which I would use for a bigger application, ie. having three projects (one bootstrap .exe, one assembly with all the app code, and one assembly with all the tests).