User stories for classic ASP unit testing example

This is the second part of a series illustrating a way to unit test classic ASP.

In part one we discussed the beginnings of the requirement and why we want to unit test classic ASP.

Here, we will explore the deliverable at hand and step through the beginnings of the use of our the framework (note, this is a fictional scenario derived from the real one I was working on).

We have an order system that we want upgrade so that between certain times the system will not take orders. Before this "down period" you can raise orders for delivery today, during the "down period" you cannot place orders and after this "down period" you can raise orders for delivery tomorrow. If this is a Friday, as we only deliver orders on weekdays we want to ensure the delivery date is for Monday and at this time we do not want to account for holiday periods.

If we translate this into some simple user acceptance criteria we can work against the following:

As a user, if I access the system before 13:00 I should be able to enter orders and they will be scheduled for delivery the same day.

As a user, after a cut off time of 14:00, I should be able to enter orders and the delivery will be scheduled the following workday. If an order is placed after 14:00 on a Friday it should be scheduled for delivery on a Monday.

As a user if I access the system between 13:00 and 14:00, I cannot place an order and the system will provide an appropriate message.

As an administrator I should be able to modify the cut off time and "next order time" and this should affect other user story times.

With the above user stories we can see that there will be a number of business rules within the code and this is the whole point of this series - ensuring we can support the coding of them with unit tests that can be run regularly.

Posted at at 11:01 PM on Wednesday, October 29, 2008 by Posted by Justin Davies | 0 comments Links to this post   | Filed under: ,

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.

Posted at at 10:09 PM on Thursday, October 23, 2008 by Posted by Justin Davies | 1 comments Links to this post   | Filed under: ,

Alt.Net London beers night - 14th October 2008

With a collection of many respected developers present the topic of the day was Domain Specific Languages. This was selected as the most popular from a number of topics posted to the "board" and just beat Inversion of Control to the post, among many others. No one was to know how contentious the topic could become when a common definition for the term was called for.

It appeared there was some difficulty in expressing the term in a consistent fashion which caused the session to become rather mired in justification conversations as opposed to exploration and better understanding. However, with a push from the moderators we did get to some valuable descriptions of examples in action to shed light on what exactly was trying to be expressed by the term DSL.

I personally had very little Domain Specific Languages other than the many blog posts on the subject by Oren Eini (Ayende). It was however very useful to me to watch the exploration of a subject in the park bench format, having not attended an event such as this before.

For me, the night spoke about "business rules" and the power a DSL could have in closing the communication gap between business domain knowledge experts and developers. By providing a common platform for rules that are more easily understood by our business partners we can deliver something that truly speaks in their terms and pushes the system into delivering benefits that really match their needs.

Of course, any abstraction comes at a price, but with a very rule-heavy business I can imagine that the development and maintenance cost of an intermediate language would pay dividends in the long term on complex systems with a shared responsibility for the working definitions of a system.

Roll on the next beers night.

Posted at at 11:02 PM on Monday, October 20, 2008 by Posted by Justin Davies | 0 comments Links to this post   | Filed under: