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.
Disclaimer
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 https://github.com/brisebois/WindowsAzure.Unity.Demo
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)
{
processor.Process();
Thread.Sleep(10000);
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 http://go.microsoft.com/fwlink/?LinkId=166357.
return base.OnStart();
}
}
Continue Reading…
Like this:
Like Loading...
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.
In my previous post 
![image_thumb[59]](https://alexandrebrisebois.files.wordpress.com/2012/09/image26.png "image_thumb[59]")
![image_thumb[63]](https://alexandrebrisebois.files.wordpress.com/2012/09/image30.png "image_thumb[63]")
Alexandre Brisebois ☁ 