To read the article online, visit

Advanced Techniques with NUnitAsp

By Tim Stall


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:

  1. WebMain, an ASP.NET Web application project, and
  2. 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:

private void Button1_Click(object sender, System.EventArgs e)
    this.Label1.Text = this.TextBox1.Text;

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:

  1. 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;

  2. 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

  3. 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";

    //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;

    //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:

  1. Abstracting common functions to a base class
  2. Using Wrapper Pages
  3. Ensuring that each test resets to a baseline
  4. Creating simple Integration and Functional tests
  5. Running your tests in the Visual Studio Debugger
We'll start our examination of these topics in Part 2.

  • Read Part 2

  • Article Information
    Article Title: ASP.NET.Advanced Techniques with NUnitAsp
    Article Author: Tim Stall
    Published Date: January 26, 2005
    Article URL:

    Copyright 2017 QuinStreet Inc. All Rights Reserved.
    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers