Archives For TDD

How do you build features on #Azure?

For the past few months my team and I have been using git-flow to build a new REST API for an existing cloud native application. The challenge was impressive, but this is how we did it.

Our team is spread across many geographical locations. We use a mix & match of best practices to help us communicate. For example, we use Skype, it’s on all our devices (phones, tables, laptops and desktops…) and makes collaboration easy! Our code lives in Git and is continuously built and released to our integration environment for validation.

Our team isn’t unique. Many of my colleagues work in distributed teams. Surprisingly, we all share the same common challenges. Time zones, cultural differences and language barriers are now part of each decision we make. Fortunately we all speak a common language, C#.

With this added complexity, how did we go to production on time? We implemented a process that we continuously tweak and adjust to meet our goals. Continue Reading…

My Reading List for 2014

January 2, 2014 — 2 Comments

book worm Every year I hunt for new books to read. 2013 was a wild year where I didn’t really have a plan in place and my reading was all over the place. Wanting to get organized in 2014 is all about not missing out.

Last year I read some great books about SQL Server, Windows Azure and methodology, this year I want to focus on catching up some more on those key books that greatly affected our industry. Are there any books that shouldn’t be on my list? What’s missing from the list?

I probably won’t get to read everything on my list, but with your help I can try to pick the best ones to read this year and continue working down the list next year.

2013 was a slow year for reading, because my focus was mostly geared towards sharing what I had learnt about Windows Azure through my blog. This year is going to be different, I will try to balance my efforts between writing and catching up on the past.

Continue Reading…

images (3)In my previous post Building Windows Azure Services Without Compromising Testability I demonstrated how the Unity Application Block can be used to build a testable Windows Azure Service. Since then I started to play with the ServiceLocator in order to introduce a new testable code base in a brownfield environment.

As many of colleagues would agree, the ServiceLocator is often considered to be an anti-pattern, but there are some scenarios where it shines. Introducing an Inversion of Control (IoC) container in a brownfield project is a scenario where the ServiceLocator can be leveraged in order to reduce risks.

When we start working on a brownfield project, the outcome of our modifications is usually quite unpredictable. Rewriting the entire code base is costly and very risky. The lack of documentation makes it hard for a team to rewrite modules without forgetting features and accounting for undocumented behavior. The ServiceLocator can be used to introduce the IoC container without significantly altering the structure of the application. We can start introducing the new code base in very targeted areas. Consequently, allowing us to bring the application under test. Furthermore it allows us to refactor and reorganize the architecture of the application from within. As the project evolves its important to keep in mind that as we overhaul the brownfield project, the ultimate goal is to factor out the ServiceLocator in order to keep the IoC Container confined to the application’s bootstrap. This of course is not something that can be achieved instantly, it takes time and planning.

Continue Reading…


Do you feel helpless when you think about testing your project’s code base? Does testing your Windows Azure solution involve deploying to Windows Azure?

Then you’re probably wasting precious time. Granted that we can’t go without testing code that consumes Windows Azure Services like the Windows Azure Queue Storage Service, but they can be abstracted and removed from our core business logic!

A few weeks back I wrote about wrapping third parties to protect against breaking changes. This post follows a similar path and will demonstrate how the Unity Application Block can be used to build a testable Windows Azure Service.


I personally do not use IoC (Inversion of Control) Containers on projects that do not absolutely require them. In some cases it ends up creating lots of accidental complexity.

Using an IoC Container like the Unity Application Block can greatly benefit a project if techniques like mocking and test driven development are used to help drive quality throughout the application’s development. On the other hand, if your application is tested by a Quality Assurance team through the UI (User Interface), then your application may not absolutely need the extra complexity created by the use of an IoC Container.

Demo Project

To demonstrate how to use the Unity Application Block in order to build Windows Azure Services without compromising testability I built the Message Processor. Get the source from

The Message Processor is a component that is responsible for reading messages from a Windows Azure Queue Storage Service, decoding the messages and processing them using Message Handlers.


The Worker Role uses the Unity Application Block to wire up the Message Processor’s dependencies. Consequently, a team of developers can build and test it’s dependencies independently. Furthermore, the only dependency on the Unity Application Block should belong the Worker Role project. Other project should not be aware that you are using an IoC Container. Keeping this dependency to a minimum will help reduce the risks of additional complexity, which could be added to you application due to the miss use of the Unity Application Block. Consequently, keeping the dependencies to the Unity Application Block to a minimum, will also give you the flexibility to change your IoC Container in the future.

public class WorkerRole : RoleEntryPoint
 public override void Run()
     // This is a sample worker implementation. Replace with your logic.
     Trace.WriteLine("Worker entry point called", "Information");

     using (var uc = new UnityContainer())
         uc.RegisterType<ILogger, TableStorageLogger>();
         uc.RegisterType<IMessageSource, QueueMessageSource>();
         uc.RegisterType<IMessageDecoder, QueueMessageDecoder>();
         uc.RegisterType<IMessageHandler, CommandHandler>("CommandHandler");
         uc.RegisterType<IEnumerable<IMessageHandler>, IMessageHandler[]>();

         var processor = uc.Resolve<MessageProcessor>();

         while (true)
             Trace.WriteLine("Working", "Information");

 public override bool OnStart()
     // Set the maximum number of concurrent connections 
     ServicePointManager.DefaultConnectionLimit = 1000;

     // For information on handling configuration changes
     // see the MSDN topic at

     return base.OnStart();

Continue Reading…

Test For Positives

September 30, 2012 — Leave a comment

When you build your test plans, it’s quite important to keep in mind that testing for positives is always easier to maintain. Furthermore, by testing for positives, you are effectively testing and documenting your actual requirements.

Tests should follow what I call the golden path. The golden path is the most direct path to reach your goal without taking any of the permutations into account. This means that If I’m testing a login screen, I will test each of its features separately.  Just to be clear, a failed login which provides the user with the proper feedback is a feature. Error messages are part of the requirements and should have specific tests.

Don’t test for unknowns. Testing for something that is undefined or unpredictable can greatly complicate your test plans and can lead to false positives. Testing for negations can pretty much result the same way.

image_thumb[59]The following example, will be using Coded UI Tests (CUIT) and Visual Studio 2012 Premium to test the login window for a small WPF application.

The Login Test Application is quite simple and composed of two WPF windows. The sole purpose of the first window is to create and show the  Login window.

The Login window is composed of a user name, a password (clear text), a login button and an error message. image_thumb[63]

The first step to building maintainable Coded UI Tests is to build a UIMap per application screen. The goal here is to keep the UIMaps as simple as possible. It’s strongly recommended to regularly prune UIMaps by removing unused controls from the UI Control Map and unused UI Actions. Doing this will greatly simplify future modifications and additions to the UIMap.

Get the code @

Continue Reading…

[2015/05/13] The code in this post has been updated to work with the “Windows Azure Storage 4.4.0-preview” NuGet package

Applying the ModelCommand pattern I was able to create a command that enables us to upload a serializable object as JSON and store it in an existing Blob Container.

Continue Reading…

Commands can be complicated to test and reuse. In a previous post, I demonstrated how to build reusable testable Queries, in this series of posts I will show you how to build commands which can be tested and reused.

This small yet powerful interface can help you build commands which respect SOLID principles like the Single Responsibility Principal (SRP), the Open/Closed Principle (OCP) and the Dependency inversion principle (DIP).

public interface IModelCommand<in TModel>
    void Apply(TModel model);

Continue Reading…

Query encapsulation can become quite empowering. For instance, query objects can be decorated, extended and reused. They allow us to implement concepts like targeted caching or user defined queries. They even allow us to execute the same query on two different data sources.

In part 2 of this series, we will be looking at how we can leverage the IModelQuery interface to enable us to reuse queries. Continue Reading…