Load Test - Binding Context Parameters

The new Load Tests features that are coming with Visual Studio 2013 are great. In combination with Windows Azure and TFS Controllers, you can run load test using cloud infrastructure without having to deploy or configure something things on the cloud.
When developers start to create different web test that will be used for load tests they usually them in sub-tests and reuse them when is possible. For example very easily you can end up with something like this:

• Foo1WebTest
• Foo2WebTest
• Foo3WebTest
• BigFooWebTest

Where BigFooWebTest make calls to Foo1WebTest and Foo2WebTest.
If you started to extract context parameters from each web test you will observer a pretty odd behavior. By default it is not possible to bind a context parameter. This means that you will not be able to fetch data for a context parameter from a data source like a csv file or data base.
Even if you will write to the value of the parameter context the binding command (“{{..#TableName.CollumnName}}”) you will observe that this will not work. When you will run the test, the value of the context parameter will be the string value itself “{{..#TableName.CollumnName}}”.
In this moment it is not possible to bind a context parameter. The only available solution in this moment is to write a plugin for the test that will load the values from data source in memory. This plugin will be able to set the value of context parameter with the memory values.
For more information about load test plugin: http://msdn.microsoft.com/en-us/library/ms243153.aspx

Read More

Load Test using Windows Azure and Visual Studio 2013

In a perfect world I would except to be able to run a load test or a stress test using a cloud provider without being forced to change any line code from my tests. 

In this article we will find out how to do this thing using the new cloud service. How a person without knowledge of cloud will be able to run a load test with 50.000 users for 24 hours with minim costs, without being obliged to purchase and configure 10, 20 nodes.

What is a load test?
What is a load test in fact? An expression that I think it fits when we need to answer this question would be: ”Are you ready to be so popular?”.  The main scope of this kind of test is to define and validate the maximum load that a system can have without affecting the performance. Even though the developer tells that the system can handle without any problem 1000 users in the same time, the load test can prove the contrary even on simple scenarios.
There is a tiny difference between the load test and stress test. Many times the load test finishes with a stress test that has the purpose to observe the behavior of the system in the moment when the load increases above the maximum supported capacity.

What the market offers us now?
At this moment it is full of different solutions for automated testing and for running load tests. Products like Selenium, LoadStorm or Neoload dominate the market. Besides them there are many others and I don’t think 10 pages will be enough to enumerate them.
If we use an on-premise solution then we need to be prepared to resolve things like the acquisition and reservation of the resources for the load-test. In a small company it will be very hard to buy 10 servers just to run the load-test. A big company, even if it has the financial resources it will take a while until this resources will be available and sometimes it might be too late. Besides all this factors the configuration of each machine and deploy can be the labyrinth from which we won’t be able to find a way out.

What is the Microsoft proposal?

On this extremely mature market, Microsoft appeared with an ingenious solution. If they already have a powerful and robust infrastructure for cloud why don’t use it to run load tests using Azure. Even though they are not the first ones that are offering this kind of solution, Microsoft has an advantage. They allow you to run load tests using Azure without using a new configuration. All you have to do is to have an account on Visual Studio Team Foundation Service (http://tfs.visualstudio.com/) which will be used for the receipt.
 Before a load test using Microsoft could have been done only through Load Test Ring. This if formed from a controller that controls the tests- Load Test Controller and one or more agents on which our tests run. An architecture that is based on master-slave. The new version of Visual Studio 2013 provides us a new option- instead of running our test in our own Load Test Ring we can run them on Azure, without a new configuration. We don’t have to deploy any virtual machine or to configure different services.
 
Load Test Web Service
Load Test Web Service is the new Azure service that helps us. Through this service, Visual Studio 2013 loads our tests on the cloud. Behind this service is a pool of test agents that is used to run our tests. This thing happens behind the scene and we don’t have to do anything for this to run. All the results from our test together with other performance counters are available for us.

Which are the main characteristics?
Before looking over different functionalities that are supported I propose to first take a look at the most important options that are supported now.
We have the possibility to define UI tests and more. Beside the fact that we can record our UI tests we can also write our custom tests and hit different endpoints. The tested endpoint doesn’t have to be only HTTP or HTTPS. We can also test a WCF or REST endpoint and also a web service. The only condition is that the endpoint must be accessible via internet.
Visual Studio 2013 brings a project template- Web Performance and Load Test Project. This type of project will allow us to define and run load tests on cloud.

How to create a new load test?
The easiest way to create a load test for a web application is to create one or more Web Performance Tests. This type of test can be UI tests which are very easy to create and to automate. Using the UI recorder that comes with Visual Studio 2013 we can create a Web Performance Test in just a few seconds. This type of test can be modified at any time and if we want we can generate code for the test. Through this method the ones that wish to write code to modify the code can do this very easily. Of course that functionality like automatically detection of the dynamic elements that the page has or to extract different constants as parameters is supported out of the box.
For each test of this type we can generate different sources like database, CSV or XML file. You can also use the tests written in Selenium for example. Each test can call other test and this way we can reuse the logic that we already have for testing.
Until now we saw how we can create a test can be used for the load test. It is time for us to see what a load test allows us to do.

Which are the main functionalities?
The first thing we need to do in order to create a load test is to THINK. We can define different profiles and time intervals through which we should be able to simulate a real user. For example we can simulate a delay of X seconds after each test. We have available different profiles which we can use.
The way we simulate a load test can be made through different methods. We have the possibility to run a test with a specific number of users or we can define the number of users to increase at every step. Of course that most of the times we will have to run different scenarios in the same time. That why we can select the tests that we want to run and in what proportion, but also the way that this test have to run. For example we can specify how many times a test should run in a time interval or which is the number of users that have to run a specific test in every moment while the load test is running.
We can simulate different browsers that the clients might have and different types of connections. The most interesting thing is that we have the possibility to add and access not just performance counters from the clients but also the ones from the servers on which our application is running. This way we can monitor and see the counters from both the client and the servers.

How to run a load test in cloud?

Until now we saw the main options that we have available to run a load test, but we didn’t saw how to run this type of test. All we have to do to run the load test on cloud is to open the Local.testsettings and on General tab to select “Run tests using Visual Studio Team Foundation Service”. This is the only thing we have to do to run the test on cloud. Of course that we have to be logged uni in Visual Studio with an account that is connected tp Visual Studio Team Foundation Service.

What is the price?
For this moment the service is on preview. Each user has 2000 virtual minutes per month that can use for the load tests. There aren’t fixed prices for this. If you need more minutes for load tests all you have to do is to enter in the early adoption program without additional costs. You will have 200.000 virtual minutes per month that you can use. Accepting the request takes very little time (in my case around 6 hours).
The first time I heard about virtual minutes I wondered what these are. A virtual minute is the duration of the load test multiplied with the number of users.
Once we run the tests we will have access to all the results including performance counters, failed tests, error messages and different diagrams. All the results can be exported into an Excel that will automatically contain the diagrams that you can show it to the clients.

I invite you to try the new cloud service for load tests. I was pleasantly surprised by this service and I think it will make our life easier.

Read More

How to write unit-tests for async methods

All developer that works with .NET heard about Task, async, await – Task Parallel Library (TPL). Great library when we need to write code that runs in parallel.
With TPL, writing code that run in parallel is pretty simple. This is great, but of course, all code that run in parallel need to be tested also – unit tests. Do you know how you need to write unit tests for async calls?
I so pretty strange way of unit tests for async methods. Some of them were ugly and complicated. Why? Because the unit test method is a sync one and there we try to run and wait a response from an async call. This is why we can end up with something like this:

        [TestMethod]
        public void MoveFile_ExistingFile_ResultsFileMovedAndOriginalFileDeleted()
        {                        
            StorageFolder destinationFolder = null;
                        
            Task.Run(() => destinationFolder = 
                                CreateFolderAsync(_originalFolder).Result)
                                  .Wait();
            
            var fileToMove = StorageHelper.CreateFile(_originalFolder,FileName);

            Task.Run(() =>  _fileManipulator.MoveFileAsync(fileToMove, destinationFolder))
                                  .Wait();

            Assert.IsTrue(_fileManipulator.Exist(destinationFolder, FileName));
            Assert.IsFalse(_fileManipulator.Exist(_originalFolder, FileName));
        }   

or

        private void SaveContent(byte[] originalContent)
        {
            Task saveTask = Task.Run(() => _applicationFileManager
                                  .SaveAsync(FileName, originalContent));
            saveTask.Wait();

        }

What do you thing? Do you like to have in the unit tests calls to Task.Run(). Personal I don’t like this and for me is a big smell. Something we are doing wrong, we are missing something.
What we are missing is the way we are writing the unit test method. By default, when we are wring a unit test we define the unit test method in this way:

[TestMethod]
public void SomeTest() { }

This is okay for testing a sync call. But when testing async call we have more option. It would be nice to be able to have our test method as an async method. In this way we don’t need to call Task.Run().
The reality is that we can define a test method like this:

[TestMethod]
public async Task SomeTest() { }

Doing this we can call our async method as a normal method and test accordingly.

        [TestMethod]
        public async Task MoveFile_ExistingFile_ResultsFileMovedAndOriginalFileDeleted()
        {                      
            StorageFolder destinationFolder = null;
                     
           destinationFolder = await CreateFolderAsync(_originalFolder)
         
            var fileToMove = StorageHelper.CreateFile(_originalFolder,FileName);

            await _fileManipulator.MoveFileAsync(fileToMove, destinationFolder);

            Assert.IsTrue(_fileManipulator.Exist(destinationFolder, FileName));
            Assert.IsFalse(_fileManipulator.Exist(_originalFolder, FileName));
        }

This feature works only on Visual Studio 2012.
On Visual Studio 2010 we need to install a NuGet package called AsyncUnitTests-MSTest. This will allow us to use async and await in our unit test. We will need to replace the TestClass attribute with AsyncTestClass. This attribute is able to run normal tests also.

In this post we saw how easily we can run unit tests for async code, without having to hack our calls.

Read More

Windows Azure Storage Emulator and testing servers

When you start to work with Windows Azure Storage Services like blobs or table you will need to specify an account name and a secret key. Working with the Windows Azure Storage Emulator you ask yourself what credentials I should use.
The good part of the story is that Microsoft offers us a default account name and key that can be used to access the storage. This can be used with success whey you want to use the local storage emulator:

Account Name: devstoreaccount1
Account Key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

Basically these are universal credentials that can be used on all the Windows Azure Emulator instances. The purpose of this is only for development and testing.
When you are staring development an application you should know that the path to the resources is a little bit different between the Windows Azure and your local machine. Your local resources are accessed using a path in the following format:

http(s)://127.0.0.1:10000/myAccount/myContainer/myContent.txt

When we are using a real blob, our path would be similar to this:

http(s)//myAccount.blob.core.windows.net/myConainer/myContent.txt

There is a little difference of the path. This small difference can make a big different when we want to start to isolate our testing machine 100%.
The first think that we can do is to set the connection string to “UseDevelopmentStorage=true”. This will solve your problem if you don’t have hardcoded file paths. Otherwise you should define different file path to blob storage if you are using an emulator or the storage from cloud.
If you are asking yourself – Where is the content of the blob stored where I’m using emulator? – the response would be in the following path:

C:\Users\myAccount\AppData\Local\dftmp\s0\...

This is the path to all your content.
Another solution for your problem is to map all your content from the blob on your servers IIS and play a little with the DNS. In this way you could “emulate” the real storage emulator without the need to have the Windows Azure Emulator installed on the server.
From my perspective the best solution to create a server where you test your application is to isolate all requests that use Windows Azure Storage and group them in a component. When you would test the application you would use a mock component that would use directories and files.
In this way your testing machine would be isolated 100%. Also testing that access to Windows Azure Storage works is an integration test of a component/resource and this is not your main goal.

Read More

How to test a connection string on the server

De cate ori nu ati patiti sa ajungeti pe un server unde ati facut deploy la o aplicatie si sa va treziti ca nu aveti conexiune la baza de date?
O soluție simpla pentru a testa conectivitatea la o baza de date SQL Server, fără sa fie nevoie sa instalați sau copiați o aplicație este sa ne folosim de un fișier uld (Universal Data Link).

1. Creați un fișier cu extensia udl (fisier nou in nodepad si "save as" cu extensia udl)
2. Dublu click pe el, iar apoi mergeți la tab-ul "properties"
3. Selectați providerul (in cazul nostru SQL Express)
4. Adaugați datele de conexiune (ip, user parola)
5. Apăsați butonul de "Test Connection"

Daca testul de conexiune se termina fără succes înseamna ca baza de date nu este accesibila.

Read More