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.