Since not too many people have played with the first community tech preview release of Visual Studio Team System's web testing (codenamed Ocracoke), I thought I'd share some basics about web tests.  Fundamentally, a web test is just a list of requests that simulate a user's interaction with a web application.  Some web tests may be designed to stress a web app by being run under heavy load and other web tests may thoroughly validate that the web app's features are working correctly.

A web test will usually be created by using the browser recorder to record a series of requests.  Below, you can see a very simple web test I recorded:

This web test is about as basic as it gets.  I browsed around the ASP.NET commerce starter kit (aka IBuySpy) and added a product to my shopping cart.  This web test could be run individually to make sure none of the requests result in server errors or as part of a load test to look for any performance problems.  While this level of testing may be sufficient, you could go one step further and add a validation rule that actually verifies the shopping cart contains the product I selected.  You could also databind the ProductID parameter to a database so that each virtual user selects a different product.

Web tests like the one shown above can handle a large chunk of testing scenarios, but sometimes you need more control.  Coded web tests give you the ability to using branching and looping constructs, perform custom databinding, and much more.  Since coded web tests are written in a .NET language, you can make use of the entire .NET framework as well as any other code.  I'll cover coded web tests in more depth in a future post, but here's the C# code generated by converting the web test shown above to a coded web test:

public override IEnumerator<WebTestRequest> GetRequests()
    WebTestRequest request1 = new WebTestRequest("");
    request1.ThinkTime = 6;
    yield return request1;

    WebTestRequest request2 = new WebTestRequest("");
    request2.ThinkTime = 4;
    request2.QueryStringParameters.Add("CategoryID", "15");
    request2.QueryStringParameters.Add("selection", "1");
    yield return request2;

    WebTestRequest request3 = new WebTestRequest ("");
    request3.ThinkTime = 2;
    request3.QueryStringParameters.Add("CategoryID", "17");
    request3.QueryStringParameters.Add("selection", "4");
    yield return request3;

    WebTestRequest request4 = new WebTestRequest("");
    request4.ThinkTime = 9;
    request4.QueryStringParameters.Add("productID", "378");
    yield return request4;

    WebTestRequest request5 = new WebTestRequest("");
    request5.ThinkTime = 10;
    request5.QueryStringParameters.Add("ProductID", "378");
    yield return request5;

As you can see, the object model closely matches the web test tree view you saw in the screenshot.  That's because non-coded web tests use the exact same object model internally.

What do you think?  Any questions or comments about web tests, coded web tests, or Ocracoke in general?