Get rid of switch statement

Yesterday I saw a piece of a legacy code that was written around 4 years ago. It is a plain old generic http handler that implements IHttpHandler interface. This handler is used for a simple data exchange between client code and a server through AJAX calls. This handler simply takes parameter sent from the client side and process them using some complex logic and switch statement. Let's take a look to a simple version of such handler. Let's imagine that our handler do some math operations:

public class Calculator : IHttpHandler
{

    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "text/plain";

        var operation = context.Request.Params["operation"];

        var a = int.Parse(context.Request.Params["a"]);
        var b = int.Parse(context.Request.Params["b"]);

        var result = 0;

        switch (operation)
        {
            case "add":
                result = a + b;
                break;
            case "subtract":
                result = a - b;
                break;
            case "multiply":
                result = a * b;
                break;
            default:
                throw new NotSupportedException(string.Format("Operation {0} is not supported", operation));
        }

        context.Response.Write(result);
    }

    public bool IsReusable
    {
        get
        {
            return false;
        }
    }
}

It's pretty straight forward. The problem comes when we need to support a lot of operations. Then our switch statement becomes really big and heavy. How can we fix it!? Probably we need to do some refactoring. But first I'd extract all that logic to a separate class, so that our handler will take params pass them to the service and write a response back to a client. Another good reason to have a separate service is an ability to test our logic. So let's create a math service and call it from the handler.

public class MathService
{
    public int Perform(string operation, int a, int b)
    {
        switch (operation)
        {
            case "add":
                return Add(a, b);
            case "subtract":
                return Subtract(a, b);
            case "multiply":
                return Multiply(a, b);
            default:
                throw new NotSupportedException(string.Format("Operation {0} is not supported", operation));
        }
    }

    private int Add(int a, int b)
    {
        return a + b;
    }

    private int Subtract(int a, int b)
    {
        return a - b;
    }

    private static int Multiply(int a, int b)
    {
        return a * b;
    }
}

Now our handler looks like this:

public void ProcessRequest(HttpContext context)
{
    context.Response.ContentType = "text/plain";

    var operation = context.Request.Params["operation"];

    var a = int.Parse(context.Request.Params["a"]);
    var b = int.Parse(context.Request.Params["b"]);

    var mathService = new MathService();

    var result = mathService.Perform(operation, a, b);

    context.Response.Write(result);
}

Now our switch is inside MathService and it would be really cool to refactor it, but first we need to cover existing logic with unit tests in order to be sure that everything works as before after refactoring.
Let's write simple tests:

[TestFixture]
public class calculator_tests
{
    [TestCase("add", 3, 5, 8)]
    [TestCase("subtract", 3, 5, -2)]
    [TestCase("multiply", 3, 5, 15)]
    public void should_calculate_ints(string operation, int a, int b, int expectedResult)
    {
        var calculator = new MathService();

        int result = calculator.Perform(operation, a, b);

        Assert.That(result, Is.EqualTo(expectedResult));
    }
}

We have three operations in our service and three test cases. Now we are good to go.
What we can do here it's try to implement a design pattern called Match or Matcher. The point is that each our operation is a separate class and each class that presents math operation has a method called IsMatch so that we can peak up a right one from the list of all available operations. Let's switch to code.

public abstract class MathOperation
{
    private readonly string _operationName;

    public MathOperation(string operationName)
    {
        _operationName = operationName;
    }

    public bool IsMatch(string operationName)
    {
        return _operationName == operationName;
    }

    public abstract int Perform(int a, int b);
}

public class Add : MathOperation
{
    public Add() : base("add")
    {
    }

    public override int Perform(int a, int b)
    {
        return a + b;
    }
}

public class Subtract :  MathOperation
{
    public Subtract() : base("subtract")
    {
    }

    public override int Perform(int a, int b)
    {
        return a - b;
    }
}

public class Multiply : MathOperation
{
    public Multiply() : base("multiply")
    {
    }

    public override int Perform(int a, int b)
    {
        return a * b;
    }
}

We have a base abstract class MathOperation that has two methods: IsMatch and abstract method Perform. IsMatch checks if operations is appropriate, in our case we check using operation name, of cause in real situation we might have more complex logic. Now let's change our MathService.

public class MathService
{
    public int Perform(string operation, int a, int b)
    {
        var operationsList = new MathOperation[]
            {
                new Add(),
                new Subtract(),
                new Multiply()
            };

        var operationHandler = operationsList.Single(o => o.IsMatch(operation));

        return operationHandler.Perform(a, b);
    }
}

We defined a collection of the operations and using LINQ we take a single one that matches by operation name. Now let's run our test and we see that everything is OK. The good thing about it that we easily can add new operations and we can test each operation separately.

Make your tests human readable.

We started to use selenium tests almost 2 years ago and since that moment we changed our approach twice. At the very beginning we had only one person involved in that process, we had a lot of "copy/paste", because all tests are more like a complex scenarios with some prerequisites and dependencies. So there were obviously a need to refactor everything and make code more clear and maintainable. I definitely should mention that each test had over 60 lines of code and two test usually had around 80% of duplicated code that means we had a lot of  "copy/paste". The first and most obvious way to fix all these shit was to create a base class and put there all common logic. Each logical block in a separate method. So that we got rid of global "copy/paste" between test and achieved the reusable parts.

Life became easier but there still were a room for improvements. We wanted to have tests writen in a such way that even a not technical person could read it. We wanted some kind of a DSL. And then we tried a SpecFlow. It looked very cool and we were encourage to try it. But it turned out to be that SpecFlow did not feet our needs due to a couple things:

• It's built over regular expressions to match scenario and real code, but has no intellisense and no tools that prevent misspelling
• In some cases we have really complex setup and it's really hard, I'd rather say impossible, to describe it in SpecFlow way.

We decided to go our own way and create our own DSL. Actually we created following:

• Base class with protected methods like: Login, Logout, GoToPage, OpenXxxWindow etc.
• Helper classes to work with cookies, with Selenium Web driver etc.

It became better. Here is a small example of how our code looked at that period of time:

[TestFixture]
public class customer_should_be_able_to_order_a_book : BaseTest
{
 [Test]
 public void customer_should_approve_delivery_after_successfull_shippment()
 {
  LoginAsCustomer();
  {
   OpenBookStoreWebPage();

   FindBook();

   AddToTheBasket();

   CheckOutTheOrder();
  }

  LoginAsManager();
  {
   GoToOrders();

   FindAnOrder();

   ConfirmShippmnet();
  }

  LoginAsCustomer();
  {
   GoToMyOrders();

   ApproveDelivery();
  }
 }
}

Actually not bad...but there are some issues which such approach does not solve. In order to make it clear I warn that curly braces after LogincAsCustomer does nothing except group methods bellow in one logical context. Login method has two implementations: LoginsAsCustomer and LoginAsManager. Let's imaging the situation when we want to write a scenario with two customers, obviously we will create another method with ugly name LoginAsCustomer2 or LoginAsSecondCustomer and so on in case we need three or four customers simultaneously. Or another example...now we have step ApproveDelivery for customer, but we might want to have an ability to approve delivery on behalf of a customer, it means that our manager will need another method with slightly different name ApproveDeliveryOnBehalf or something very similar. But what we really wanted it some context specific approach. Ability to use the same method login that is aware about which credentials to use.
I'm totally into DI and loosely coupled code, I want to have small and well described steps for my tests. Let's look how should look simple step, as an example I will show Login step.

public class Login : BaseStep, IExecutableStep
{
    public UserCredentials _userCredentials;

    public Login(UserCredentials userCredentials)
    {
        _userCredentials = userCredentials;
    }

    public void Execute()
    {
        //fake implementation
        Logger.Log("Login: {0}", _userCredentials.Login);
            
        Logger.Log("Password: {0}", _userCredentials.Password);
    }
}

For demo purpose this code doesn't interact with database or some other services, it only logs in console user credentials. It has Execute method from IExecutabeStep, each step in our scenario should be executed :) so all steps should implement this scenario. And it also has a BaseStep as ancestor we will look later at BaseStep more deeply. Login step should know a credentials to use. It means that our login step has a dependency and we need a way to solve it some how. And the most interesting thing that we can resolve it differently according to execution context. And this is the time to show what is execution context.

public interface IExecutionContext
{
 void AddContextBindings(IKernel kernel);

 void RemoveContextBindings(IKernel kernel);
}

My implementation is based on Ninject, it's open source IoC framework. Those who don't know what is Binding probably should get famiilar with Ninject or some other IoC container. Actually it's not so complicated. IKernel it's an interface that has very useful method Get which accept a type. Let's say we want to create an instance of Login step, then we will call

kernel.Get<Login>();

very simple, the thing is that by itself Login type is a public class and could be easily instantiated, but there is one issue. We have a dependency on UserCredentials and we need to know where to get this credentials. Here comes another method of kernel, it's method Bind. Most likely you would do something like this:

kernel.Bind<ISomeInterface>().To<SomeImplementation>();

Here we say that every time we want instance of ISomeInterface we should create an instance of SomeImplementation which should be obviously derived from ISomeInterface. In our case we want to have some user credential aware context, just like this one.

public class UserAwareContext : IExecutionContext
{
    private readonly UserCredentials _userCredentials;

    public UserAwareContext(UserCredentials userCredentials)
    {
        _userCredentials = userCredentials;
    }

    public void AddContextBindings(IKernel kernel)
    {
        kernel.Bind<UserCredentials>().ToConstant(_userCredentials);
    }

    public void RemoveContextBindings(IKernel kernel)
    {
        kernel.Unbind<UserCredentials>();
    }
}

Here we say that we want to resolve UserCredential by some specific object with some specific login and password. We can create two or more such contexts each with unique credentials, one for customer another for manager and so on, let take a look how to do it:

public class Users
{
    public static UserAwareContext Customer()
    {
        return new UserAwareContext(new UserCredentials
            {
                Login = "john",
                Password = "orange"
            });
    }

    public static UserAwareContext Manager()
    {
        return new UserAwareContext(new UserCredentials
            {
                Login = "manager",
                Password = "cherry"
            });
    }
}

It's a factory that knows how to create a context. So I can use Users.Customer(); and it will return we a customer context or I can  use Users.Manager(); and it will return me a manager context.
Now it's time to get everything together, our code will look like:

var customer = Users.Customer();

As(customer).Execute(() =>
{
    Do<Login>();
}

Let's talk about As and Do methods. As creates execution scope, it accepts IExecutionContext as parameter, a collection of IExecutionContext if to be more precised. And register all dependencies using AddContextBindings method. Then we call method Do which resolves step instance using all bindings declared in As method and then call Execute method of that step. Before to leave execution scope we need to remove all bindings that were declared at the beginning, at this point we need a method RemoveContextBindings of the interface IExecutionContext.

I almost forgot about BaseStep, this is how it looks.

public class BaseStep
{
    [Inject]
    public Logger Logger { get; set; }
}

Logger is marked with Inject attribute, it's a ninject attribute, that allow to mark a public property as a dependency that has to be resolved.

Source code and another examples are available on the bitbucket.
Later I'm going to show how to use it together with Selenium WebDriver, because initially this approach was designed to maintain complex scenarios above selenium.

Source code 

Angular JS. "No image" directive

Hi everyone. I've been playing for 2 months with Angular JS and going to post a couple articles about it.
I was really impressed by a unique feature of angular js that allows to create custom tags and custom attributes using angular directives.

In our prototype we had a situation where we need to show some product details including product image.
Actually there are 3 valid cases for product image in our application:

• we don't have an image url
• we have a valid image url
• we have broken image url (server errors like 404 or 503)

Let's start with the simple solution and then will improve it.
So if we have a url for a product lets show and image with that url, if we don't have an image let's use some default image like:

Our markup will be something like this:

<img ng-show="product.imageUrl" ng-src="{{product.imageUrl}}" />
<img ng-show="!product.imageUrl" src="/demo/img/no_image_small.png" />

It's very important to use ng-src directive instead of plain old src attribute. Why ?!...actually because it takes some time to instantiate and wire up all angular stuff, it's pretty fast but anyway browser will start loading an image using "product.image" like an url, before angular will evaluate this statement.

Let's handle now the situation when url is broken. It's very simple. There is an event called onerror let's add this handler to the first image tag. And let's define a handler for such event.

<img ng-show="product.imageUrl" ng-src="{{product.imageUrl}}" onerror="setDefaultImage(this)" />
<img ng-show="!product.imageUrl" src="/demo/img/no_image_small.png" />

Javascript handler:

function setDefaultImage(image) {
    image.src = "/demo/img/no_image_small.png";
}

Everything looks simple but:

• It's hard to reuse: we will need to copy everything all the time
• It's complicated and ugly
• We introduced a global function
• It's not the Angular JS way

Let's create a directive that will handle everything we need:

app.directive('noImage', function () {

    var setDefaultImage = function (el) {
        el.attr('src', "/demo/img/no_image_small.png");
    };

    return {
        restrict: 'A',
        link: function (scope, el, attr) {
            scope.$watch(function() {
                return attr.ngSrc;
            }, function () {
                var src = attr.ngSrc;

                if (!src) {
                    setDefaultImage(el);
                }
            });

            el.bind('error', function() { setDefaultImage(el); });
        }
    };
});

Actually all magic is inside the link function. We watch ngSrc, it's an url that we set from the markup. If we don't have a url then we use default image. Bellow we attach new event handler to the element and if error event occurs we again assign default image. nsSrc here comes from attr variable, attr variable it's just a collection of all attributes assigned to the html element. You also might have noticed that we wrote restrict: 'A', it means that we are going to use this directive as an attribute over html element. Why do we use scope.$watch !? well let's image a situation when somebody dynamically changes image url, then we will need to reevaluate our url and again display real image or image placeholder.

Here goes example of usage:

<img no-image ng-src="{product.imageUrl}}" />

To make code more flexible and reusable, we should get rid of hard coded image url inside the directive.
Since Angular JS is built with DI in mind let use that approach. Let's create some settings provider and inject it inside the directive. So our code will look like this:

app.factory('settings', function() {
    return {
        noImageUrl: "/demo/img/no_image_small.png"
    };
});

app.directive('noImage', function (settings) {

    var setDefaultImage = function (el) {
        el.attr('src', settings.noImageUrl);
    };

    return {
        restrict: 'A',
        link: function (scope, el, attr) {
            scope.$watch(function() {
                return attr.ngSrc;
            }, function () {
                var src = attr.ngSrc;

                if (!src) {
                    setDefaultImage(el);
                }
            });

            el.bind('error', function() { setDefaultImage(el); });
        }
    };
});

Now in case we need such directive in other application we easily can include script to the application and define a factory that will return appropriate url.