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

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.

Edited by moderator - 16May2008 at 11:23pm