Introduction
Keeping bugs out of existing code during new development has always been a huge problem. However a new methodology,
Test Driven Development (TDD), is helping to change that. The two main principles
of this methodology are:
Never write a single line of code unless you have a failing automated test, and
Eliminate duplication.
In principle this makes sense - we'd all love to have a thousand automated tests, running at the click of a button or
command line, which guarantees that our application works. There's even a popular open source tool,
NUnit, which provides a framework for running automated unit tests. While this is very
popular with class libraries that just manipulate data structures, it is much more difficult with GUIs.
(For a more thorough discussion of NUnit be sure to read Test Driven Development Using
NUnit in C#.)
Fortunately there's another open source tool, NUnitAsp, which provides a framework to test the GUI's aspx pages.
NUnitAsp is an NUnit extension that provides the extra classes needed to test
the HttpContext used by WebForms. Therefore within your NUnit tests, you could load up a page just as a user would see it,
taking into consideration the QueryString, Session, ViewState, postback, Web.config, etc... You could then programmatically
trigger events and check the resulting properties. This opens up a whole new world for testing techniques.
The NUnitAsp website already provides a general tutorial. Rather than re-invent the wheel, this article will provide just
a quick beginning sample, and then show how NUnitAsp can solve more advanced problems. This article also provides a
downloadable code sample that contains the examples.
A Simple Example
Let's first get the "Hello, World!" of NUnitAsp tests running. Note that while in proper Test Driven Development, you
should first write the tests first and then the code that makes those tests pass, it will be much easier to explain how to
use NUnitAsp if we write the application part first.
Start by creating a new solution with two projects:
WebMain, an ASP.NET Web application project, and
UitGui, a console application that contains the Unit and Integration Tests for the GUI
In the Web project, let's create a WebForm called Basic.aspx that has a TextBox, Button, and Label. When you
click the Button, it displays the value of the TextBox in the Label. You can find this page already built in the code
sample at Simple\Basic.aspx. It has only one relevant method:
First run the project and confirm that the page does indeed work. If you can't load the page in Visual Studio, you likely
won't be able to run it in NUnitAsp. In this simple example, we want to make sure that the TextBox-Button-Label flow works
correctly.
In the UitGui project, add a reference to both nunit.framework.dll (version 2.2) and NUnitAsp.dll
(version 1.5.1). These are contained within the code attachment, or downloadable from their respective websites. Then add a
new class called TestBasic.cs. To make this class run with NUnitAsp, you need only a few simple steps:
Make the class references the namespaces from the NUnit and System DLLs:
using System;
using System.Web;
using NUnit.Framework;
using NUnit.Extensions.Asp;
using NUnit.Extensions.Asp.AspTester;
In the class declaration line, add the [TestFixture] attribute to let NUnitAsp know this class contains
tests. Then make the class inherit from WebFormTestCase, which provides a Browser property for
loading web pages and some extra assertions to check test conditions.
[TestFixture] public class TestBasic : WebFormTestCase
Make sure that the constructor is public so that external programs (like NUnitAsp) can instantiate the
class and call the tests:
public TestBasic() { }
We are now ready to write our first test. First let's look at the code, and then discuss what it does.
[Test] public void SelectDropdown()
{
string strURL = TestConstants.AppPath + "Simple/Basic.aspx";
Browser.GetPage(strURL);
//declare the controls:
ButtonTester Button1 = new ButtonTester("Button1", CurrentWebForm);
LabelTester Label1 = new LabelTester("Label1", CurrentWebForm);
TextBoxTester TextBox1 = new TextBoxTester("TextBox1", CurrentWebForm);
//run through actions:
string strValue = "Hello";
TextBox1.Text = strValue;
Button1.Click();
//check values:
WebAssertion.AssertEquals(strValue, Label1.Text);
} //end of method
The test starts with a standard NUnit method declaration. This requires the [Test] attribute, a void
return type, and no parameters being passed in. Next we form the URL for the page to load and send it into the
Browser object's GetPage() method. Note that we have abstracted out the domain name
(like http://localhost/myprojects/) to a constant class rather than hard code it for all tests.
Once the Browser.GetPage() method gets the page, we can create AspTester objects for standard
server controls. The constructor requires the Asp Id and the container control (such as the CurrentWebForm, or
a User Control object).
The real value begins once we've created the AspTester objects because these let us programmatically access most
properties of the controls on the page, just like a live user. The page flow is simple: set the value of the TextBox and
then click the button.
Finally we need to test the final state of the page: the label should have the value of the TextBox. NUnitAsp provides
standard methods in the WebAssertion class to check our expectations of what the page should be. In this case
we want to make sure that the label equals a specific value, so we use the AssertEquals method.
Open up the NUnit console, load up the UitGui dll, and run the test. You should see a green circle next to the
test, indicating a pass:
We've now finished our first test! Even something this simple with NUnitAsp would be non-trivial without it.
"Hello, World!" is nice, but real world problems go so much deeper. This article will address the following five techniques
to tackle these problems using NUnitAsp:
Abstracting common functions to a base class
Using Wrapper Pages
Ensuring that each test resets to a baseline
Creating simple Integration and Functional tests
Running your tests in the Visual Studio Debugger
We'll start our examination of these topics in Part 2.
