Reader Notes

This article is pitched at a highly technical audience who are already working with Azure , StoryQ and potentially Selenium / Web Driver. This article primarily builds on a previous Article we wrote in this series,  in which we explain all the frameworks listed above. If they are unfamiliar to you we would suggest reading through this article first:

Agile path ways into the Azure Universe – Access Control Service [ACS] []

For those who are completely new to  test driven concepts , we might also suggest reading through the following article as an overview to some of the concepts presented in this series.

Step By Step Guides -Getting started with White Box Behaviour Driven Development []


In this article we will focus on building a base class which will allow the consumer to produce atomic, and repeatable Microsoft Azure based tests which can be run on the local machine.

The proposition is that, given a correctly installed machine with the right set of user permissions and configuration we can check out fresh source from our source control repository and execute a set of tests to ensure the source is healthy. We can then add to these tests and drive out further functionality safely in our local environment prior to publication to the Microsoft Azure.

The one caveat to this proposition is that due to the nature of the Microsoft Azure Cloud based services, there is only so much we can do in our local environment before we need to provide our tests with a connection to Azure assets (such as ACS [Access Control Service] , Service Bus). It should be noted that Various design patterns outside the scope of this article can substitute for some of these elements and provide some fidelity with the live environment. The decision on which route to take on these issues is project specific and will be covered in further articles in coming months.


Our own development setup is as follows:

·Windows 8

· Visual Studio 2012

· Resharper 7

· NUnit

· NUnit Fluent Assertions

- Azure SDK [Currently 1.7]

We find that the above combination of software packages makes for an exceptional development environment. Windows 8 is by far the most productive Operating System we have used across any hardware stack. Jet Brains Resharper has become an indispensable tool, without which Visual Studio feels highly limited. NUnit is our preferred testing framework, however you could use MBUnit or XUnit. For those who must stick with a pure Microsoft ALM experience you could also use MSTest.

Azure Emulator

The Microsoft Azure toolset includes the Azure Emulator , this tool attempts to offer a semi faithful experience in the local development environment of a deployed application scenario on windows Azure. This is achieved by the emulation of Storage and Compute on the local system. Unfortunately, due to the connected nature of the Azure platform in particular the service bus element , the Emulators ability is some what limited. In the Test Driven world a number of these limitations can be worked around by running in a semi-connected mode (where your tests still have a dependency on Microsoft Azure and a requirement to be connected to the internet )  for the essentials that cannot be emulated locally.

With forward thinking , good design and Mocking / Faking frameworks it is possible to stimulate the behaviour of the Microsoft Azure connected elements. In this scenario every decision is a compromise and there is no Right or Wrong answer, just the right answer at that time for that project and that team.

Even with the above limitations the Emulator is a powerful development tool. It can work with either a local install of IIS or IIS express. In the following example we will pair the emulator with IISExpress. We firmly believe in reducing the number of statically configured elements a developer has to have to run a fresh check out from source control of a given code base.

Task 1 – Configure the emulator arguments in the app.config file

The first task is to set up some configuration entry’s to allow the framework to run the emulator in a process , these arguments define:

  • Path to the Azure Emulator
  • Path to the application package directory
  • Path to the application service configuration file

The first step is to add a app.config file to our test project


Note – a relative root can be configured for the CSX and the Service Configuration file , in this example to keep things explicit we have not done this.


    The first argument we need to configure is the path to the emulator, on our machine using SDK 1.7 this is configured as follows :



The second argument we need to configure is the path to the package, for our solution this looks like:



The third argument we need to set up is the path to the services configuration file. For our solution this looks like this:


[Use IISExpress switch]

The  final argument we need is to tell the emulator to use IISExpress as its web server:


The final Configuration group:


Task 2 – We build the process command line

Now we have the argument information captured in the application configuration file we need to build this information into an argument string. We have done this in our Test / Specification base:


In the TestFixtureSetup [called by child test classes]

  • Declare the arguments as variables
  • We assign the values  from the applications configuration file to our new variables
  • We then build our argument string and assign it to _computeArgs

Task 3 – We setup the emulator and execute it in a process

Now we have all the information we need to pass to our process to execute the emulator; our next stage is to start a process and host the emulator using the arguments we have just defined.


The code is relativity trivial

  • Spin up a process inside  a using block
  • Pass in the emulator arguments
  • Wait for the process to finish
  • Report on the output
  • The Should().Be() is making use of Fluent Assertions

Task 4 – Add code to our roles to make them publish a azure package when they build

Since Azure SDK 1.4 , Role projects have not automatically created package contents for azure. We need this to happen so that we can use a small code fragment which we add to the azure project file.


Reference Posts

Task 5 – We  now execute our tests

Now with the emulator + iisexpress running we are free to execute our tests / specifications from our child test / specifications fixtures.

Step 1 the Emulator starts



Step 2 IISExpress hosts the site




Step 3 [Optional] Selenium + web driver open browser and run tests




Task 6 – Shutting down the emulator

The emulator and the service can be quite slow in ending; it is possible to use the arguments in the following article to remove the package and close the emulator down. However we have encountered issues with this so instead we prefer to kill the process. We suggest you find out which one works of these approaches works best for your situation. Reference Article Our code



Points of note

You must configure azure to use IISExpress at a project level The emulator does not like being shut down manually half way through a test run. If you have to do this make sure you end the service process also. This is an advanced technique with a number of moving parts, as such it is advised that you should pactise it on a piece of spike code before using it on a production project.
This technique is limited by the constraints of the SDK and the Emulator

Recap –What have we just done

  • We have configured the information required by the process and the emulator in an application configuration file
  • We have run up a process which starts the emulator + iisexpress
  • We have configured publish for emulator in the azure config
  • We have run our tests / specifications against the azure emulator
  • We have shutdown both iisexpress and the emulator
  • We are now green and complete.


This has been quite an advanced topic , to define these steps has been a journey of some research and experimentation that we hope to save the reader.

The purpose of this technique is to try to empower the principal that a developer should be able to simply check out source on a standard development configured machine and the tests should just run. They should be atomic , include their own setup and teardown logic and when they are finished they should leave no foot print. There is no reason we should break this principal just because we are coding against the cloud.

It is also important that tests are repeatable and have no side effects. Again the use of techniques such as those demonstrated in this short article help to empower this principal.

Happy Test driving


Twitter  @martindotnet

Elastacloud Community Team