Archives For Testing


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…


boy-taking-exam

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.

2013-04-14_23h32_56

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…

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.


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…


Queries are complicated to test and nearly impossible to reuse. In systems of all sizes they get duplicated,  modified and augmented to the point where we are afraid to modify them. They are essentially questions about data that generate information upon which we can act. They should be reusable. They should be predictable and above all, they should be testable.

Continue Reading…