CodeKicks.com
Focus on Microsoft Technologies - Tutorials, Articles, Code Samples.

Friday, August 25, 2006

Testing ASP.NET using NUNIT and NUNITASP

What’s the Problem?

NUnit is an indispensable tool. I use it every day to tell me whether or not I know what I’m doing. Its only major drawback is that the code you test has to be run inside the NUnit test runner process. For most applications, this isn’t a problem. The only “container” you are worried about is the CLR; it doesn’t really matter what the actual executable is. If you need to model external objects for your code’s consumption, you can always knock out some mock objects, either on your own or with a tool like NMock (http://nmock.truemesh.com).

When this does become a problem is trying to test your ASP.NET code. Not the middle-tier logic you tie into, but the .aspx pages themselves. How can you test that the UI reacts to the user correctly? That the postback events happen in the right order? That the correct next page is loaded after the user completes the page? Testing these things requires that your code is running inside the ASP.NET worker process. Your pages need access to the HTTPContext, the Request and Response objects, everything else that ASP.NET provides them at runtime. If you attempt to test your compiled .aspx pages directly from the NUnit test runner, none of them will even load, let alone pass your tests.


NUnitASP is the Solution

Sure, you could write up a bunch of mock objects to convince your pages that they are really running in ASP.NET. However, that list would include:

  • The page “intrinsics”: Request, Response, Application, Server, and Session
  • The webcontrols: TextBox, Button, DropDownList, etc.
  • The context: HTTPContext

You would spend much more time writing this mock framework than writing any unit tests for your own application.

NUNitASP, an open-source (MIT license) application, provides this framework for you. Or, more to the point, it let’s your pages run in the actual ASP.NET worker process, but allows you to create a mock façade container to test the UI with. This façade creates all the server-side web- and html-control objects present on your page, whose properties you can manipulate and whose events you can fire. Then, you can check the results (of a postback or cross-page navigation).

To allow for this testing, NUnitASP has to provide not only a mock container for your pages but a browser imitation object that acts as the requesting client. The browser imitation object is what allows you to test the current URL, the cookies collection, and the static HTML output of a request. The collection of mock server controls allows you to manipulate and test the server-side properties and behavior of your pages.

Getting Started

First, you will need to download the latest version of NUnitASP (http://nunitasp.sourceforge.net/download.html). The download comes with an installer for the latest version of NUnit, which you will also need if you don’t already have it installed. To install, NUNitASP, simply unzip it into the folder of your choice and you are done.

To get started using it, create a new ASP.NET Web Application project (or load up an existing one that you want to test) and add references to nunit.framework.dll (in the NUnit install’s bin folder) and nunitasp.dll (in the NUnitASP install’s bin folder). For this article, we’ll be creating a simple application consisting of four pages:

  1. default.aspx: the main entry point into our application. If the user is logged on, it will display their name. Otherwise, the label containing the user name will be invisible.
  2. securepage.aspx: a web form that is marked as <deny users=”?”/> in the web.config file. This means that unauthenticated users cannot load the page.
  3. logon.aspx: a web form that allows a user to logon to the website.
  4. forgot.aspx: the web form to allow users who have forgotten their password to retrieve it or create a new one.

The web.config file for our application has the following sections in it:

<authentication mode="Forms">      <forms loginUrl="logon.aspx"/></authentication><authorization>     	<allow users="*" /></authorization><location path="securepage.aspx"><system.web>		<authorization>			<deny users="?"/>		</authorization>	</system.web> </location>

These sections establish that we are using Forms Authentication for our security mechanism, that “logon.aspx” should be loaded whenever a non-authenticated user attempts to access a page.

Continue it by theserverside….

Technorati Tags:
43 Things Tags:
Buzzwords (Buzznet) Tags:
Del.Icio.Us Tags:
Flickr Tags:
Ice Rocket Tags:
LiveJournal Tags:

Post a Comment