Use Azure development storage from unit tests

Learn the two options for your persistent data storage If you're writing an application that's going to use Windows Azure.

If you're writing an application that's going to use Windows Azure, you have two options for your persistent data storage (aka your database). Option #1 is SQL Azure which is Microsoft's relational database in the cloud. Option #2, Azure Storage, is similar to a relational database but is better thought of as "structured storage". Reasons to choose one Azure storage option over the other, is a discussion that's outside of the scope...

of this article but basically comes down to performance and cost.

If you're writing a Windows Azure application and have chosen to go the Azure Storage route, you get a convenient local version that run on your desktop called Development Storage. Development Storage (DevelopmentStorage.exe) supplies a set of REST-based Web service endpoints that behave exactly the same as the cloud-based, production Azure Storage endpoints. Since development storage runs on your local machine rather than on Microsoft's servers, you don't have to pay for your usage.

So, what does this have to do with unit tests?

Well, if your unit tests depend on Dev Storage's endpoints to be running and active, you need to make sure that DevelopmentStorage.exe is running and properly initialized before the tests start to execute. The problem is that DevelopmentStorage.exe only gets automatically started when you start debugging a cloud application project in Visual Studio. Sure, that's not the end of the world but it's kind of inconvenient to manually start it and it's annoying when you're suddenly staring a list of unit tests that are all failing.

 If your unit tests are failing because DevelopmentStorage.exe isn't running, you'll get an error like the one in the below that says something like "System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:10002."

 The hint here is the part of the error saying that there was a problem trying to talk to 127.0.0.1 (localhost) on port 10000, 10001, or 10002. These are the ports for Azure Storage's Blob, Queue, and Table REST endpoints respectively.

 The solution for how to get DevelopmentStorage.exe running is to hook in to the initialization events for either Visual Studio's unit tests (VSTest) or NUnit. In VSTest, you can hook in to these events by decorating a method in your unit test with one of the initialization attributes: TestInitialize, TestCleanup, ClassInitialize, ClassCleanup, AssemblyInitialize, and AssemblyCleanup.

Attribute Usage Description
[TestInitialize] Apply to a public instance method that takes no parameters and returns void. Executes immediately before each unit test method.
[TestCleanup] Apply to a public instance method that takes no parameters and returns void. Executes immediately after each unit test method.
[ClassInitialize] Apply to a public instance method that takes no parameters and returns void. Executes before the first unit test in a test fixture is executed.
[ClassCleanup] Apply to a public instance method that takes no parameters and returns void. Executed after all unit tests in a test fixture is executed.
[AssemblyInitialize] Apply to a public static method that takes an instance of TestContext as a parameter and returns void. Executed once per a test suite execution and is run before the first unit test executes.
[AssemblyCleanup] Apply to a public static method that takes an instance of TestContext as a parameter and returns void. Executes once per test suite execution after all unit tests in the test suite have been executed.

For most of my Azure Storage-based unit tests, I find that AssemblyInitialize is what need. Hooking in to AssemblyInitialize allows me to make sure that DevelopmentStorage.exe is running before any other tests have started to run and remains available for the entire duration of my test suite execution.

It all comes down to checking whether development storage is already running and, if it isn't running, issuing a command line call from .NET using the Process and ProcessStartInfo. ProcesStartInfo describes the program to be called as well as the arguments. Create an instance of ProcessStartInfo that points to "C:\Program Files\Windows Azure SDK\v1.0\bin\csrun.exe" with the "/devstore:start" argument and then pass it to a Process object and call Process.Start() followed by a call to Process.WaitForExit(). It's important to remember to call WaitForExit() because if you don't, your unit tests will start running before development storage has finished initializing and your unit tests will fail.

Below is the code you can add to your Azure Storage unit tests to start development storage.

 [AssemblyInitialize()] public static void AssemblyInitialize(TestContext context) { StartAzureDevelopmentStorage(); } private static void StartAzureDevelopmentStorage() { var count = Process.GetProcessesByName("DSService").Length; if (count == 0) { ProcessStartInfo start = new ProcessStartInfo(); start.Arguments = "/devstore:start"; start.FileName = @"C:\Program Files\Windows Azure SDK\v1.0\bin\csrun.exe"; var proc = new Process(); proc.StartInfo = start; proc.Start(); proc.WaitForExit(); } }

Now when you run your unit tests, you'll see a command prompt window pop up saying "Starting Devstore" followed by a message in your system tray saying that the Windows Azure Simulation Environment's Development Storage is started. Now, if all goes well with your code, your unit tests should be passing.

 

This was first published in February 2010

Dig deeper on Windows Azure development

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudComputing

SearchSoftwareQuality

SearchSOA

TheServerSide

SearchCloudApplications

Close