How to Unit Test Classic ASP

This is the first in a series of posts that will attempt to illustrate a basic way of unit testing classic ASP. We will explore the motivations behind the series and our thought processes when building the framework.

The first thing that may cross many minds is - why?

Well, some companies still have large systems running the foundations of their business in classic ASP and shedding this restrictive technology doesn't prove easy or quick. In these scenarios, when we are working on classic ASP we want to ensure that where we can, we are still bringing best practices to the table and delivering positive benefits with the code that we write regardless of the age of the technology.

First, a caveat... I hadn't worked on classic ASP for about 6 years until my current contract where I am now occasionally helping to maintain such a system. But when I did come to use it I was staggered by how loose, unconstrained and un-testable "typical" ASP code is - I had simply forgotten what VBScript and the ASP model was like. So I decided to go about creating a mini-framework for testing the classic ASP code I was writing so that I could ensure what I was writing was testable. If I get a few things wrong, or there are better ways of doing it, please do chip in and guide the way!
I also realise that some developers may already have a handle on classic ASP and are doing some of the things shown in this series (or better) and in that case this is not for you! It is primarily aimed at those maintaining and improving hard to manage spaghetti ASP code within an existing application.

In this series of posts I hope to show how you can leverage NUnit (replaceable with your own test framework) to wrap a custom ASP test framework that we will build from scratch.

I have found that the "usual" cycle of development on classic ASP follows a pattern of:

Code, run the main html-outputting .asp page.
Code, run the .asp page. Repeat.

After only a short while of doing this it was clear that this was not a good way of testing the code that we were writing for a number of reasons:

  • it is time consuming
  • feedback loop is very long
  • we are testing the whole and not component parts of logic
  • it is very loose and in testing everything, we in fact test hardly anything

What do I mean by that last statement?

Well, in my mind, in running the asp page, what we are actually testing for is that:

  • it doesn't have a runtime error
  • the html on the page is correct, or we get the desired effect (such as a Response.Redirect)

All the code in the middle, including the business logic is assumed to be working correctly because the effect of it running is matches our desires. This is not the same as whether the code works correctly -we are testing it in one particular form of usage and there may well be hidden bugs in the code waiting for future changes to cause side effects or issues.

If we can find a way to start testing the component parts of the code we can begin to gain confidence that the code we are writing matches the delivery requirements.

In the next part of this series, we will look at a particular change scenario and associated user stories so that we can examine the creation of a framework within a particular context.


  1. Anonymous March 3, 2011 at 9:12 PM

    Caught of in similar situation, and i am finding your views useful.