Preparation Tasks and Concepts

The main content of this article depends upon an Azure Service called ‘Access Control Service’. To make use of this service, you’ll need to sign up for an Azure Account. At the time of writing this article there is a 90 day free trial available.


You can find the portal entry page and sign up page at this web address : [ ]

The wizard will take you through the sign up process, including signing up for a live account if you do not have one currently.

What is Azure?

Azure is Microsoft cloud offering , in very simple terms Microsoft provide huge containers full of hardware across the world and from these hardware clusters, Microsoft offer you the ability to:

  • Upload and consume Virtual Machines
  • Upload your own websites, applications and services
  • Consume specialist services for example Access Control Service [ACS]
  • Distribute your content worldwide via the Content Delivery Network [CDN]
  • Make use of Object based data storage using a variant of  NoSQL concept called Table Storage
  • Online SQL server instances , known as Azure SQL
  • Distributed messaging and workflow via powerful and custom service bus offering.

In simple terms, Azure gives you the power to focus on writing world class software whilst it handles the hardware and costing concerns. All this power comes with a price tag, but when you take into account the cost of physical data canters Azure is more than competitive. In this article we will only utilise a tiny fraction of the power of Azure, but we would encourage you to explore it in more depth if you haven’t already.

What Is the Access Control Service [ ACS ] ?

Web Address – [ ]

The Access Control Service offered by Microsoft via the Azure platform is a broker for Single Sign On Solutions. In simple terms this provides the capability for users to Authenticate to use your application. This authentication uses commercial and trusted Identity Providers such as:

  • Google
  • Windows Live Id
  • A custom identity provider or a corporate Active Directory.
    Once a user has authenticated they are issued with a token. We can receive and use this token as a unique identifier for the user inside the target software system.
    This is as far as we will go to explain ACS, there is a lot of high quality material available on the internet that covers the basics of getting up and running with ACS . We have included a number of in depth links below, but the rest of this article will focus on Test driving ACS.

Adding Internet Identity Providers like Facebook, Google, LiveID and Yahoo to your MVC web application using Windows Azure AppFabric Access Control Service and jQuery in 3 steps

How to Authenticate Web Users with Windows Azure Access Control Service

Re-Introducing the Windows Azure Access Control Service

Behaviour Driven Development and black box testing – Concepts

Behaviour Driven Development or BDD has been in common use for a number of years, and there are several  flavours available in a number of frameworks. The basis of BDD is that we execute living requirements (or in Agile speak, Stories) which have been written in a English readable representation of the required functionality.

Some frameworks take a Domain Specific Language (DSL) approach to defining the requirements that the BDD tests will execute, a common standard is called Gherkin.

DSL  : [ ]

Gherkin : [ ]

The framework we will be using in this article is called StoryQ ([ ]). We have chosen this framework due to its simplistic approach to specification design, and more importantly its support for coded specifications. To be specific; we write the specification in code and therefore they become part of our living code base.

Driving the Browser

Although StoryQ provides a nice step by step format and structure to our Stories, it still leaves the problem that the requirements are written from a high level perspective.

As developers, we could implement a White box style approach where by we do not respect the outer borders of the application. Our Tests would then be allowed to interact with the code, and even substitute parts of the code for Testing objects such as Mocks. We speak about this approach in detail in this article.

[ ] .

In this case we have elected to respect the boundaries of the application. We will treat the application as if it is within a black box, into which we can not see or interfere but with who’s public interface (in this case a web page) we can interact.

Having made this decision we now need to find a framework to work with StoryQ. We need to allow our tests to drive a browser and cause it to replicate a users interaction. There are a number of frameworks available , in this case we select the excellent Selenium  + Web driver packages from Nuget.

[ ].

The tools we are using

Our own development setup is as follows:

·Windows 8

· Visual Studio 2012

· Resharper 7

· NUnit

· NUnit Fluent Extensions

– Selenium + Web Driver

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.

What are we trying to achieve

In the rest of this article we will demonstrate using Selenium + Web Driver to empower our StoryQ tests. We will show how to represent a User logging into Azure [ACS] prior to them accessing our site.

We will show illustrations of the following

  • Web Driver
  • StoryQ
  • Azure Access Control Service
  • Emergent Design
  • NUnit
  • Unit Testing a controller action
  • Selenium Selectors
  • Identity and Access Tool

Test Driven

As Test Driven Developers we start with a requirement and a Test –

As A User who is not logged in

When I try to access the site

Then I expect to be taken to a login screen

Step 1 : Is to add a Test Assembly this is just a standard class library project.


Step 2 : Add Nuget references for –

    • Nunit
    • StoryQ
    • Fluent Assertions


Step 3 : Write a Story –


Note on Story Planning

The Story above reflects the spirit of the original requirement, but actually attacks them in a very pragmatic way. This will not appeal to purist BDD folks, but it is an approach we have found to be very effective when analysing requirements from Business. We often find that some of the set up and Administrator stories have been missed from the planning, and that these are required to empower the pure business Story’s.

We can also see here that the motivation for the ACS integration has changed to the Administrator. This would of typically come out of a conversation with a Business Owner over who this Story benefits and which role would be motivated by the security of the system.

The business would typically readjust their Story pallet to include Stories relevant to User profile and data security that arise from discussion with the business owner. This allows us to refine the Stories provided to the developers and better reflect the businesses intentions. The above situation illustrates the cooperative requirement management process with the Agile space. It is a good example of iterative requirement planning as a requirement passes through different stages of planning.

If we execute a dry run of this story –


we see the following output –

Story is We are forced to login to ACS when trying to access the site
In order to keep the web site secure => (#001)
As a Administrator
I want users to have to authenticate via ACS prior to entry to the web site

With scenario Happy Path

Step 4 : Write the scenario –


Step 5 :Generate Step Stubs


Recap – What we have done so far

We have taken the following steps –

  • Set up a environment
  • Built a class library project
  • Set up a story
  • Set up a scenario
  • Stubbed out the steps required by the scenario

If we dry run the story now we see the following output –


Lets take a closer look


We can immediately see what we need to do to make this test pass, and in a very human readable output. This is one of the amazing and empowering features of StoryQ; it’s ability to bridge the gap between technical and business, via its clear and precise output formats.

Note – this is still a bit of a technical story, terms such as ACS would probably need to be refactored or added to a product definition dictionary, for the sake of this article we have kept this wording in.

Implementing the Functionality and making the story pass.

Next we start to use the test steps defined in the Story to drive out our functional foot print. In the following sections we will start to make formative steps to construct the application. The ACS bridge being built through the Azure side of the configuration will not be covered, as this has been covered in depth by the links supplied in earlier sections of this article.

Steps illustration

Now lets get started with the implementation.

Step 1 : That I am Not Logged In

This step forces us to use Nuget to bring in the webdriver and selenium implementation we referred to earlier. The main reason we are driven to do this now is because we want to be sure we have no ACS cookies registered with the browser. To delete any cookies that are present we need to make a call to the browser. This also gives us our perfect motivation to bring down a browser automation tool kit.


With the Webdriver in place we can now instantiate it and make sure we have cleared down any cookies and are working with a fresh profile. There are drivers available for Firefox, Internet Explorer and Chrome. In our case we have used Firefox.


With the Driver in place and instantiated we can now make sure it is clear of cookies.


We are being explicit here despite the fact we have just created a new Profile. This is because the step cannot be dependant upon the set code, the driver or profile to remain unchanging.  We therefor include a deliberate step to delete all cookies and make sure we are working with a clean browser.

Step 2 : I Try To Go To The Home Page

In this step we will see a browser window open up and try to browse to the site. To enable this we are driven to add the following elements –

  • App.Config
  • ASP MVC Application
  • Home Controller
  • Index Action
    When we can see that the browser launched by the framework automatically navigates to the home page then we know this step is complete.
The code to drive the browser –


    The settings for the test runner, held in a app.config file for convenience.


We now add a ASP MVC 4 project


When we run the story we can see Firefox open and try to navigate to the Home URL, which fails.


We will now add a Unit test to drive out the Home controller and index action.


From this test we drive out the view and the controller, we have added them below for completeness.





The controller and view are skeletal objects, we only implement what we are driven to add by our tests.

We now rerun our test and find that we are green. We are ready to continue our journey.


With the new controller and view in place we will re-run our Step and see if we can reach the site. Unfortunately we find we still fail – this is because the default is for visual studio to use the development server. We can work with this, but when working on the types of sites that we will be running via the Azure Emulator, we prefer to work directly with a IIS or IIS express. Eventually, as mentioned above, we would more than likely be driven by our none functional requirements to implement the Azure emulator. However as we have not been driven there yet, we will configure visual studio to run this site via IIS.

The links below will explain how to configure your choice of web server for your project to run under.

[ ]

[ ]

With IIS configured we have proved the potential for this step to succeed. We can see below that without ACS implemented we are successfully able to Test Drive to the Home action of the site.


StoryQ guides our efforts by showing a textual map of what we have done and what we have left to achieve.


Step 3 : I Am Taken To The ACS Provider Chooser Page

To Achieve this step we need to add some acceptance criteria and then we need to configure ACS. First let us set our expectations for this step.


In the code above we have a search to retrieve all div elements on page, followed by a Query to make sure the ACS sign on text can be found in the collection. Note that there are many elements that we could have checked on the page, including a fragment of the URL. As there was a choice, we have chosen to select just enough to get the job done and fix the Query and Criteria if it proves to be problematic.

Note: the selection criteria above will vary dependent upon the Identity providers you have configured. The above criteria works when we have selected multiple identity providers, in this case google and Windows Live.

The next step is to configure the pathways to ACS. For this to succeed you need to have configured an ACS namespace as per the directions supplied on the links earlier in this article.

Identity And Access Tool





The Identity and Access Tool can be used to bypass a lot of manual configuration and pain. It is a substantial improvement on the WIF tool kit. Below is a link which provides details of how to configure the tool .

Note: We have, on occasions, found that we have needed to restart Visual Studio 2012 multiple times when installing this tool, before the Identity and Access option has been available on the context menu.

Note: We have found with our ASP MVC projects when using this tool, that we then need to add some namespaces as reference. You can check what these are by taking a quick peek at the web.config file.


We found we needed to add System.IdentityModel.


If you want to check your configuration , set the ASP MVC project as the start up project and press f5 to run the project. Depending on the identity providers you configured, you should be presented with a challenge page.


Once you have logged in you , you should be presented with your Home page for your ASP MVC Application


With the ACS bridge in place and properly configured, we will now head back to our Story and the step we were completing. We need to rerun the test to check the expectation.



After running the test Firefox starts up and goes to the ACS page. The text inside the div is found and we have another passing step in our story as well as a configured ACS bridge.

Next we will pick an identify provider. We will then login to the ACS page using the web driver and authenticate.

Step 4 : I Have To Pick A Identity Provider

We will use the web driver to login to Windows Live as the Identity Provider.


We can now execute this step


Success –  The test now executes the step to take the driver to the Windows Live login page

Step 5 : I Have To Login To My Identity Provider

To provide this functionality we have written a few extension methods. There is no magic here, the secret of this technique is in its simplicity.  We need only do the following :

  • Find the relevant elements on the page
  • Enter the expected Text
  • Click a button
  • Capture a confirmation dialog and accept it
Step implementation


Extension Methods


The ACS provider after the Email address and Password have been filled in


Success – The Home screen, post click of submit button and acceptance of Confirmation Dialog


Test output showing passing step


Step 6 : I am Taken To The Site

The final step asserts that we are in fact on the home page and we are done


Let us now execute this test and hopefully we should have a green passing story.



Recap – What have we just done

Let us just take a moment to take a breath and look back at what we have achieved.

  • We now have a ASP MVC 4 application shell
  • The ASP MVC 4 application shell is integrated with ACS
  • We have security test coverage across the homepage. We can add other scenarios to our Stories if we want to make them implement ACS security.
  • We have introduced the the concepts of Black Box Browser based BDD.
  • We have had a short discussion about the need to reinterprete and reframe requirements


    In this short article we have introduced a lot of new material ,and supplied a number of links to in-depth discussions and tutorials on the  relevant subject areas. It is our hope that this acts as a spring board to deeper learning and fun with Azure, ACS and BDD.
      Author Beth
      Follow @Martindotnet