A load test completes with status ‘Completed’. If one needs to learn more details on the run, they should open the result file (trx) and read the statistics. Now, in real world something can go wrong with either the infrastructure or one of the system components. Let’s say that one of the element in a long Web test fails for a reason. In such case you would rather not wasting time analyzing the result of the test to find it out only ten, but write it off automatically.

You can implement a load test plugin which will do the whole work. What you need to do is to add a handler for TestFinished event, which occurs every time an iteration (a Web or unit test) finishes. In this event handler you can retrieve the information whether the iteration completed successfully or not. Depending on such information you can continue (i.e. do nothing) or abort the test (possibly returning a meaningful error message). A sample OnTestFinished event handler could look as below (test is an instance of the LoadTest class):

private void OnTestFinished(object sender, TestFinishedEventArgs e)
{
	if (!e.Result.Passed)
	{
		test.Abort(new Exception("One of the load test's iterations failed..."));
	}
}

Please refer to Gabriel Szlechtman description on how to create a plugin for a load test to get more information on the structure of the plugin and how to hook it to the load test.

That’s why at the time of deploying the changes, you probably should temporarily switch off the service and display the appropriate message so that the user knows the web site is being updated, and that is happening now.

Now, if you are hosting the service on IIS this is very simple to achieve. All you need to do is copy app_offline.htm to the root directory of your web site. Once the file is in place, it will be served to the user as a response to any request to your web site. Once you’re done with deployment, remove that file and the updated service will start working again.

After this change the test stopped working – it always ended with error message: ‘User aborted test run’. Apart from that each iteration of the web test produced MethodAccessException: Microsoft.VisualStudio.TestTools.WebTesting.WebTest.set_Outcome(Microsoft.VisualStudio.TestTools.WebTesting.Outcome).

Solution

The reason for the problem was I was using Visual Studio TS 2008 without SP1. Once I installed the SP1, which must have updated mstest, the test started running successfully again.

The key point here is before SP1 Outcome was read-only property, which I learned there.

public class AWebTest : WebTest
{
    private IEnumerator<WebTestRequest> GetCommonRequests()
    {
        WebTestRequest req1 = new WebTestRequest("http://google.com");
        yield return req1;

        WebTestRequest req2 = new WebTestRequest("http://google.com");
        yield return req2;
    }

    public override IEnumerator<WebTestRequest> GetRequestEnumerator()
    {
        WebTestRequest req = new WebTestRequest("http://google.com");
        yield return req;

        GetCommonRequests();
    }
}

You would expect to see three requests in the test result. You will see only one though…

Solution

The reason for that is you make a simple call to GetCommonRequests(), and you are not returning (with yield command) the actual value to the enumerator that holds WebTestRequests. Going forward, in main test method only one web request is added to the enumerator.

To make it working you need to call GetCommonRequests() in more sophisticated way:

public class AWebTest : WebTest
{
    private IEnumerator<WebTestRequest> GetCommonRequests()
    {
        WebTestRequest req1 = new WebTestRequest("http://google.com");
        yield return req1;

        WebTestRequest req2 = new WebTestRequest("http://google.com");
        yield return req2;
    }

    public override IEnumerator<WebTestRequest> GetRequestEnumerator()
    {
        WebTestRequest req = new WebTestRequest("http://google.com");
        yield return req;

        IEnumerator<WebTestRequest> requests = GetCommonRequests();
        while (requests.MoveNext())
        {
            yield return requests.Current;
        }
    }
}

Only this way will there be three requests visible in the test result.

Luckily, load tests can be enhanced with plugins. I don’t want to describe how to create a plugin here; if you are interested have a look at a very good description provided by Gabriel Szlechtman. Following that advice you can easily extend a load test so that it stops whenever there’s a threshold violation (it is defined for a counter, e.g. page load time, CPU usage). All you need to do is to use Abort() or Abort(Exception) of LoadTest class. The latter is probably more convenient because it allows revealing the reason why the test was aborted.

At the end of a day, once the test is aborted it’s status is set to ‘Error’, which can be treated as ‘Failed’ in your automated testing process.

Now, because a coded web test can have some logic inside, it makes sense to add logging so that there’s a trace on what’s going on while it executes.

The easiest way to add a logging feature is to use AddCommentToResult method of WebTest class:

public class AWebTest : WebTest
{
    public override IEnumerator<WebTestRequest> GetRequestEnumerator()
    {
        AddCommentToResult("This is a comment");

        // test code to go there
    }
}

When you open the test result you will see something similar to this:

Of course, this is not the most convenient and appropriate way of saving the trace of the test, but there are no additional steps needed to get it working. However, if you need only small amount of very basic information you can give it a try.

So I created a new project with a plug-in class, added a reference to it from load test project and wanted to hook the plug-in with the test. However, when I was doing the last step I was getting the following error:

Solution

The fix is quite simple. When I added a new class for the plug-in, it was defined without the access modifier (and therefore it was internal), which made the class accessible from other classes only in the same assembly. Adding public access modifier for the plug-in class solved the problem.

Error occurred running test. XXX could not access the result repository: Invalid object name ‘LoadTestRun’

Solution

The reason for that was I hadn’t had created a database schema for load tests. In order to do it I executed <VS location>\Common7\IDE\loadtestresultsrepository.sql which did all the job.

Please refer to msdn for more information.

class B {
  public:
    B() { }
};

class D : public B {
  public:
    int x;
    int y;

    D(int _x , int _y) : x(_x) , y(_y +1) { }
};

Now, what if class B had a protected member (z), which you had to initialize in the derived class? It can’t be done in the initializer list. It can be done as below though.

class B {
  public:
    B() { }
  protected:
    int z;
};

class D : public B {
  public:
    int x;
    int y;

    D(int _x , int _y, int _z) : x(_x) , y(_y +1) {
        z = _z;
    }
};

Looks simple but if you are switching to C++ after several years it no longer must be so

After several years of working with Java, C#, SQL and web technologies in general, there’s some time to use the other languages. Among others I’ll be writing some C++ code from time to time now.

I used C (and alittle bit of C++) when I was a student but that were all small projects and it was years ago. Now, it’s obvious I need to catch up with C/C++. I happened to get C++: The Complete Reference by Herbert Schildt. The word reference implies there’s probably no point in reading this book from title-page to colophon; there’s a lot of reference data like the standard function library. However, what I really liked about this book is it gives a quick introduction to most important aspects of C/C++ (e.g. pointers, classes, references, overloading, templates), of course with obvious and numerous code examples.

Recommended. It’s worth keeping this book nearby while working with C++.