An introduction to NUnitForms with a basic example of automated Microsoft .Net Windows Forms Testing using NUnit.
NUnitForms is a lesser known extension to the well known NUnit testing framework. See http://nunitforms.sourceforge.net/ for details and downloads. It is currently in the process of being upgraded from .Net Framework V1.1 to V2.0 and is only being distributed as an MSI with no source code (except via CVS as Adam pointed out below).
I have found it quite useful but the documentation was lacking and the learning curve a bit painful, hence this post! I will assume that you have NUnit and NUnitForms installed for the following code samples to run.
How can NUnitForms be used?
NUnitForms gives a developer the ability to approach forms development from a test first perspective, or to simply provide a reliable set of automated regression tests for a user interface. (For the record, I am not getting into concepts such as model-view-controller/presenter, interface coding or the like - all I am demonstrating is how to use NUnitForms for testing.)
NUnitForms replaces (or supplements) the traditional “GUI test harness” method commonly used for GUI development. Sometime the use of even a test harness is bypassed (because of time restrictions of course!) The problem with manual test harnesses are that the typically become a mess that only the original developer can even make sense of and, all the testing is done manually. NunitForms alleviates these issues by making things automated in the first place. I am not against the use of a manual GUI test harness - they still have their benefits - but compared to automated testing they lose out big time. A useful GUI test harness example that would be hard to test in an automated fashion is control resize behaviour and positioning.
How does it work?
Basically there is a lot of reflection and forms/controls parsing to locate controls and invoke the methods that are normally performed by the user, such as pushing a button. For example, a test uses NUnitForms code that fires the “OnClick” event for a button. You put together a series of these events simulating a user and you have an automated script. That’s putting it really simply!
A Simple Example
Get a new instance of VS.Net going. I created a basic form as below:
The textbox and button are named “NameTextbox” and “RunButon” respectively (more on that later).
Add a new project for the unit testing - add references to:
- The windows application we are testing
- NUnit
- NUnitForms
- System.Windows.Forms
See sample solution setup below:
Now define a test fixture as normal (with the addition of the NUnit.Extensions.Forms using directive) but there are 2 main differences:
- the fixture needs to inherit from “NUnitFormTest” and to get the test to work at all.
- we need to override the “Setup” method. In this setup method we create an instance of the form and show it.
Make sure you show it or you will go crazy trying to debug the problem (yes I forgot!) The setup method is called before each test so we start with a clean slate.
Now for a test. This is a dumb test, but remember we are looking at the concept!
When I push the “Run” button, I want whatever test is in the textbox to become the form title, sample test:
We need a TextBoxTester and a ButtonTester. This will give us access to the button and textbox on the form. Assign a value to the textbox and invoke a “click” on the button. Now for the test, we have a reference to the test form at the fixture level so we can get the form title from there.
using System;
using NUnit.Framework;
using NUnit.Extensions.Forms;
namespace NUnitFormsDemo1.UnitTests
{
[TestFixture]
public class SimpleFormTests : NUnitFormTest
{
SimpleForm _simpleForm;
public override void Setup()
{
_simpleForm = new SimpleForm();
_simpleForm.Show();
}
[Test]
public void FillTextboxWithData()
{
TextBoxTester nameTextbox = new TextBoxTester("NameTextbox");
ButtonTester runButton = new ButtonTester("RunButton");
string expected = "From automated test.";
Assert.AreEqual("Simple Form", _simpleForm.Text, "Initial value incorrect.");
nameTextbox["Text"] = expected;
runButton.Click();
Assert.AreEqual(expected, _simpleForm.Text, "Title should be that textbox value.");
}
}
}
The test failed.
TestCase 'NUnitFormsDemo1.UnitTests.SimpleFormTests.FillTextboxWithData'
failed: Title should be that textbox value.
String lengths differ. Expected length=20, but was length=11.
Strings differ at index 0.
expected: <"From automated test.">
but was: <"Simple Form">
Now implement the code to pass the test. Here is the rocket science code back in the form:
private void RunButton_Click(object sender, EventArgs e)
{
this.Text = NameTextbox.Text;
}
Hey - I can do that without NUnitForms!
That particular test yes - with some changes to the sample form itself. The controls would need to be exposed either via a property or similar and the button click can be simulated with the “PerformClick” method. However that calls for exposing controls via properties etc which means alot more coding and to be honest we are just scratching the surface of what NUnitForms can do. The use of NUnitForms allows us to avoid that sort of "coding simply to support testing".
I hope that can get you started, more to come... PK :-)
Demo Source: NUnitFormsDemo1.zip (12.83 KB)
More Forms Testing:
Subscribe