Automated testing for Classic ASP

Question

Does anyone do automated QA testing for a Classic ASP site? I started looking at WatIn and MBUnit but not sure of the best way to structer the tests.

Answer 1

Check Selenium.

Answer 2

I tested ASP site with Watir. If you are looking for a way to structure tests, take a look at WatirCraft framework.

Answer 3

Hi Mike,

The new WatiN 2.0 beta 1 does offer some base classes to help you structure test classes.

It basically comes down to having a class for each page (inheriting the WatiN.Core.Page class). In these page classes you add properties for each control you want to access. Something like:

public Button OkButton
{
    get { return Document.Button("okbuttonId");
}

and you can create methods to wrap some more complicated actions an a page. For instance:

public void AddPerson(string name, string email)
{
    /// logic goes here tp click on NewButton, set the textfields and click on OkButton
}

These page classes offer the advantage of defining your elements in one place.

In your test code you can create a page class as follows:

using(var ie = new IE("www.somedomain.com/person"))
{
  var page = ie.Page<PersonDetailPage>();
  page.AddPerson("J. Doe", "[email protected]");

  // Do some Assert
}

Another interesting base class to help you structure your code is the Control class. When you use ASP you'll use controls which will not render to just one html element in the rendered page. Instead it will often be a construct of elements contained in a Div element. When creating your own control class and inherit Control you'll be able to wrap the controls (html) internals and behavior. This makes it very easy to reuse the control in your page classes. Following an example on how to instantiate a control:

var calendar = Document.Control<CalendarControl>("calendarId");

Hope this gives you some insight in how you can structure your Pages and controls.

Jeroen

Answer 4

FWIW, we have been using WatiN and MbUnit for web integration testing for the past 3 years.

We have separated the tests into 3 projects:

1. QA.Framework: Contains glue code for setting up test fixtures and various custom MbUnit and WatiN extension.

2. QA.SiteMap: Contains Page and Control classes arranged hierarchically into namespaces that correspond to different domains and parts of the sites. This project serves to decouple tests from the major part of the web site structure. You can think of it as a model of the sites.

3. QA.Tests: Contains the actual tests also arranged hierarchically into namespaces. Tests leverage the SiteMap and Framework as needed to interact with the web site. This way there is much less code duplication than if each test contained the same button ids over and over...

Jeff.