Why do we write tests?

We all write tests everyday. We write different types of tests from unit tests to browser automation tests. Occasionally I meet a team members who are not sure whether they should write a test or not. If yes, why she should write that test. Or whether the test they are writing is a good quality test. An example of this situation is tests for FluentNHibernate mapping classes. The argument usually is that if you know how your table is structured then there is barely anything that needs to be designed or unit tested. If you know the rules of how to write mappings then things just work. Another example is a test below.

[Test]
public void RegistrationController_Index()
{
    var controller = new RegistrationController();

    var result = controller.Index() as ViewResult;

    Assert.That(result, Is.Not.Null);
}

This test has two obvious problems

1. Just asserting that result is not null is not enough. We need a better assert. 
2. The name of the test is misleading or rather it is not leading us to anywhere. 

My experience is that, people who write such tests (or decide against writing important tests) fail to understand what value a test adds. To understand what value a test adds, we need to answer this question - Why do we write tests?

Now, I am no expert at TDD. Following paragraphs are my attempt at answering this question in a way that provides some pointers to help us with understanding what value a test adds.

Prevent induced defects - This is by far the most important reason why we write tests. We work in a world dominated by delivery pressure where code is always changing. Any line of code we change can leave some other part of the application broken. Our tests should prevent us from this. If you have got tests that are not failing even when the functionality they are testing is completely changed, then those tests are of no use. The test above is an example of such a situation. If RegistrationController is supposed to return a view Index.cshtml and I change that to return Register.cshtml, then I might have broken some important feature and this test does a bad job at telling me that.

Safety Net - This is second most important reason behind writing tests. A well written test, acts as a safety net not only when you are re-factoring your code but also when you are changing an existing feature. After changing the code, if you have no failing tests, that either means your change has not altered any existing behaviour of the system or your tests are not good at detecting this. Tests for NHibernate mappings is important from this standpoint. I would like to be prevented from someone removing/modifying a property on my model that is mapped to an existing database column.

Drive design and implementation of features - This may not apply to unit tests, but does apply to automated acceptance criteria and integration tests. A lot of times, I start my Red-Green-Refactor cycle with an automated acceptance criteria or an integration test. This leads nicely into design of controllers, models and routes that efficiently satisfy the needs to feature I am building.

Confidence in the quality of the software - A well written and complete automated test suit is an indicator of the quality of the software. I personally do not feel confident about the quality of the software if there are missing tests or tests that are not carefully written. For lot of people high level of code coverage is a factor that leads to a level of confidence in the quality of the software, for others it may be something else. But at the end of the day, the confidence does come from quality of the automated tests.

Code documentation - By code documentation I do not mean technical documentation of you product. Lot of times, we deliver a feature and nothing happens around that feature for few months. After few months product owner comes with a great idea that needs changes to that feature. People who worked on the feature originally are not around and new people have to work on the change. They would first need to understand how the existing code is working. They can look at the existing code if it is simple. But they would better off by going through the tests in order to understand the code. This works quite nicely.

Lower the frustration of testers - Testers on your team are going to be frustrated if they see that nasty defect that is beyond their means to reproduce. If you have testing developers on the team, they might find a way out on their own, but not always. It helps to think about what kind of uncontrolled environment your code would be run in (e.g. multiple concurrent requests, load etc.) and try to come up with tests that can validate code's behaviour in such situations. If you have such tests that, after every commit, are validating behaviour of software in probable uncontrolled environment, then you have a happy tester who would help with finding more important issue and save your face in front of client.

That was not a big list, huh? So every time I have a doubt whether I should write that next test or whether the test I have just written add any value, I try to look for positive answers to one or more of the following questions.

1. Will this test prevent defects induced by changes to the code being tested?
2. Will this test provide required level of safety net to other developers or to me few months later?
3. Is this test helping me with design of the code I am going to write?
4. Would this test increase my or my team's confidence in the quality of the software?
5. Can this test act as good documentation of the feature being tested?
6. Can this test help lower the frustration of other team members, especially testers?

Some questions are difficult to answers and experience is the key to getting best answers out. But I hope trying to answer these questions when you are in doubt would set you on the right path

How to choose right technology for building scalable software

I am member of a mailing list around start-ups and entrepreneurship in India. The group has some experienced entrepreneurs as members and the mailing list is always flowing with lot of good conversation and advice all the time. Recently someone asked what technology should they be using to build their next software. They wanted scalability and performance built into the software from day one and wanted right programming framework for the job. Some people responded suggesting to use PHP or Java. These suggestions mostly came from their experience of building software which is understandable.

My thoughts on this area are quite different and I responded to the thread. I feel I should share the response with my readers here.

I am a bit surprised on the answered being offered so far. I understand tendency to suggest technology that you have used or you love. But programming language/technology/platform do not offer a ready made formula for performance and scalability. I am a .NET developer and have worked on software that both scaled well and faltered. 

Think of this - Twitter uses Ruby (RoR to be specific) and at one point of time, they determined that Ruby does not scale. What was that point? That point was when more than 12 million tweets went through their networks in a span of one hour when results on US elections were being declared. This point came for twitter after being in business for more than 8 years. Till that time they were quite happy with Ruby. 

Facebook started with plain PHP and did well when user base was well below few millions. Eventually they found out problems with PHP and went on to transport their PHP code into C++. I have even heard that they have built their own PHP implementation.

Examples can go on. But one common theme across all these companies is that they do not use one technology or platform to build their services. They wisely choose tools/technologies based on lot of factors like rate at which they are growing, usage patterns, architecture of their product, latest research and lot more. 

With above background, I would summarize with following

1. Do not rely on a particular technology to offer scalability/performance. It is a carefully designed software combined with carefully designed hardware infrastructure that delivers the scalability and performance and not a programming language

2. Start with a programming language that you know or you think is easy to hire best people knowing that technology. For founders of start-ups it is best to know some programming in the beginning

3. Build the product, launch it and see how it goes. If you are a hit then you would have lot of cash to look back at your initial implementation and make changes where needed

4. Be open to using more than one programming language/technology (this is called polyglot programming)

5. Keep an eye on new frameworks/libraries and assess how you can benefit from them

6. Follow practices like TDD along with Agile that puts you in a position to make major changes to your code-base cheaply and in least amount of time

Building software that scales is more of an art. It takes various iterations of fine tuning and swiping in and out various pieces of code to see what works and what does not. There are example of high performing websites built using almost every web technology exists under the sun. The reason they scale is because they use the right technology at the right layer along with aids like CSS/Javascript minification, caching wherever possible, following correct HTTP semantics, building services in a way that minimizes chattiness etc. There is no "one programming language" solution to the problem and the solution does not come out by following a particular style of coding.

IamA Microsoft ASP.NET and Web Tools Team (and Azure) on reddit

Yesterday, Scott Hanselman, Damian Edwards and  Mads Kristensen from Microsoft were at Reddit answering people's questions and future of lot of things around web/cloud development and Microsoft. The transcript was quite informative and interesting to read. If you are a web developer using any of Microsoft's technologies or are apssionate about cloud, I highly recommend following the transcript here - AMA

I am yet to go through the whole transcript but here are some of the exciting bits I got to know about from the chat

1. They talked about how the OSS initiative started at Microsoft. How Phil Haack and ScootGu played an important role and where the OSS initiative is headed. It was interesting to know that guys have managed to open source a lot of things in last couple of years. It was also nice to know that they promote external open source .NET based web frameworks like Nanacy, ServiceStack and Oak etc.
2. Katana  project is getting serious attention. Do not be surprised if one day ASP.NET MVC works completely off Katana without any dependency on System.Web. If you have no clue what I am talking about - System.Web is part of BCL and is not open sourced. Where as, ASP.NET MVC is open sourced. MVC takes dependency on System.Web as of now which is a problem because their release cycles are not synchronised and MVC team cannot add new features to System.Web.If you are interested, the roadmap for Katana project is here 
3. Rewriting project file structure - Microsoft is listening to people's complaints about pains of XML based project file. They are working on building a new project file formats that enable more collaboration with less conflicts after committing project files. It is not clear when this would be released.
4. Offline NuGet - Again, they are listening. They are working on ideas to make NuGet available offline. Again, no news on when this would be available but effort is going on.
5. Folks at Microsoft have interest in seeing remote debugging in browsers initiative. Visit their website to know more about the initiative. It would be a good boost of web developer's productivity if this initiative sees the light of the day.
6. BrowserLink and Side-Waffle project - There are lot of interesting things happening around BrowserLink and Side-Waffle project. Take a look at Side-Waffle's github page
7. SASS and LESS support in visual Studio - VS2013 has SAAS editor to make the lives of graphic designers among us easy. And they are actively working on a LESS editor for upcoming release.
8. TypeScript - TypeScript team is working on visual studio tooling for TypeScript from ground up. This is in order to offer a richer experience. They are hoping to release TypeScript 1.0 and tooling support in Visual Studio together
9. ASP.NET Web Pages - Mind you, this is not Web Forms. I did not know this existed. Take a look here - Web Pages
10. What's happening in the world of Visual Studio
11. Microsoft's Partnership with Xamarin and what's in future around building cross-platform mobile apps in C#

Besides the above they talk a lot about future of EF, MVC and SignalR in general, what helped them reach where they are, life at Microsoft and lot of other things. The transcript is worth reading. Here is the link again - http://www.reddit.com/r/IAmA/comments/1qp91h/iama_we_are_microsoft_aspnet_and_web_tools_team/

Why Sprint.Rest client is better than RestSharp for building REST clients?

If you are interacting with any REST service then you problably have used some kind of HTTP client library. I have used RestSharp on few project. RestSharp is quite cool. You can learn more aobut RestSharp from their website. They have got an example there that talks about what you can do with Restsharp. If you have never used a library for interacting with REST services then I strongly recommend taking a look at RestSharp.

But this post is not about Restsharp. Don't get me wrong, ReshSharp is a cool and sleep library and delivers exactly what is says on the tin. There is one area though where it dis-appointed me - testability. When you are writing client code to communicate with a REST service and if you are like me, you would like that code to be unit tested. With Restsharp there is no way of mocking the actual call (or at least I did not find anything either in source code or in their documentation). Having to make real calls from the tests is a heavy affair that I would like to avoid. And I also do not want to bombard the real service with loads of requests that my client code needs to be tested for. So I was on lookout for a new REST client library. My search lead me to REST client that is part of Spring framework (not the Java one but the one built for .NET). I was amazed by the features that this library offers and immense documentation that they have got. You can find more details on their website. The part I most liked was ability to mock the service, set expectations on requests sent and return mocked responses. Let's dive into some code

Testability

One of the common tests that I write for my client is to ensure that request is being made on correct url. In case of a POST request, I also like to ensure that correct post body is being sent to server. Take a look at following test code

[Test]
public void SendsRquestOnCorrectUrl()
{
    var restTemplate = new RestTemplate("baseAddress");

    var document = new Document("master");

    var mockRestServer = MockRestServiceServer.CreateServer(restTemplate);
    mockRestServer.ExpectNewRequest()
                    .AndExpect(RequestMatchers.MatchUri(string.Format("{0}/api/document", ApiBaseUrl)))
                    .AndExpect(RequestMatchers.MatchBody(JsonConvert.SerializeObject(document)));

    restClient.PostForMessage("api/document", document);
    mockRestServer.Verify();
}

So you create an instance of RestTemplate, which is your client making HTTP connections to server. You then create an instance of mock server by calling MockRestServiceServer.CreateServer and passing in previously created instance of RestTemplate. This would now start intercepting all the calls we make using the restTemplate. Next, you set some expectations on mockRestServer. I have set following three expectations here

1. It should expect a new request
2. It should expect the URI on which the request would be made to match "ApiBaseUrl/api/document"
3. It should expect the request body to contain the JSON version of document object

Then post the document object using PostForMessage method. In the end, assert the set expectations by calling Verify() method on MockRestServiceServer.

The best part is RequestMatchers class. This come bundled with loads of various matching options that you would not have to go looking for help on internet.

And more

As I used Spring Rest client more and more, I figured out there more good things about it besides testability.

1. Less plumbing code - On most occasions, you would end up writing lesser plumbing code as compared to RestSharp.
2. HTTP Message Conversion - Library comes packaged with several message converters that can automatically convert response data from byte array, ATOM/RSS feeds, files, strings, JSON, sliverlight etc. And if you are working with a custom response format, it is not very difficult to build and plug your own message converter. 
3. Authentication - Besides supporting basic authentication, it support OAuth
4. Request interceptor - This should not be confused with mocking described above. Interceptors let you inject code at various points of request life-cycle. For example, you can start a timer just before a request is sent and stop it right after response is received and calculate the response time of the server. You can implement different interceptors for different purposes.
5. Asynch story - They have got async implementation using Task Parallel Library (TPL)
6. and lot of other features

So far I am quite happy with this library. I have not seen many people using it so it would nice to know what you think of this library. 

Fluent controller builder updates

Yesterday I blogged about a fluent controller builder that I put together. You can read about it here. While building further tests using this controller builder I soon got into trouble. My initial design catered well for simple controllers which always have default constructors. So following code worked

var documentController = Build.Controller<DocumentController>()
                              .Having(b =>
                                {
                                    b.PostRequest().At("http://localhost/api/content");
                                    b.UsingDefaultRoute().HavingRouteData("controller", "document");
                                });

 A problem with this code is that it is creating an instance of the controller for me. This works fine when controller has a default constructor. As complexity of my application grew, I soon needed to inject various dependencies into my controller and above code stopped working. To fix the problem, I have introduced a new class that lets you configure a controller instance for use in unit testing. So you control the instantiation part and pass the instance of a configuration class that would do rest of the magic. Here is how the new code looks

documentRepository = Substitute.For<IRepository<Document>>();
idGenerator = Substitute.For<IGenerateId>();
urlBuilder = Substitute.For<IBuildUrl>();

documentController = new DocumentController(documentRepository, idGenerator, urlBuilder);

Configure.Controller(documentController).AsHaving(b =>
             {
                    b.PostRequest().At("http://localhost/api/content");
                    b.UsingDefaultRoute().HavingRouteData("controller", "document");
             });

Here my controller has three dependencies for which I want to inject stubs instead of real objects. This is easy because now I can create my own instance of controller and send it in to new Configure class that would prepare my controller for unit testing.

The nuget package has been updated to include this new change. You can find the details here

Fluent controller builder for unit testing Web API controllers

This post is not about unit testing Web API controllers. A gentleman named Peter Provost has already written about this in enough details here. I actually followed his post to fix some issues with my unit tests. In order to unit test Web API controllers you need to set up a few things before you can start calling action methods.

1. Populate Request property of controller with a new instance of HttpRequestMessageClass
2. Define a route
3. Create a route data collection
4. Create an instance of HttpControllerContext using the above and use this to set ControllerContext property on our controller instance
5. Tell the request object created in first step to use the above configuration.    

Does this sound complex? It does to me, so let me show you the code that actually does the above and you would know that this only sounds complex

private static void SetupControllerForTests(ApiController controller)
{
    var config = new HttpConfiguration();
    var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost/api/products");
    var route = config.Routes.MapHttpRoute("DefaultApi", "api/{controller}/{id}");
    var routeData = new HttpRouteData(route, new HttpRouteValueDictionary { { "controller", "products" } });

    controller.ControllerContext = new HttpControllerContext(config, routeData, request);
    controller.Request = request;
    controller.Request.Properties[HttpPropertyKeys.HttpConfigurationKey] = config;
}

This code is not very complex to understand but it has lot of moving parts. For example, I may not always test for a post request or I may not always use the same route. These things change based on the context of you test. So reusing this code in multiple tests is challenging. An easy way to fix the problem is to accept most things as parameters to the method. 

Welcome to the fluent world

Being a big follower of fluent way of writing code (read more about this here) I re-factored this code. Here is how the code for controller set up looks in fluent world

var documentController = Build.Controller<DocumentController>()
                              .Having(b =>
                                {
                                    b.PostRequest().At("http://localhost/api/content");
                                    b.UsingDefaultRoute().HavingRouteData("controller", "document");
                                });

Doesn't this read natural - "Build a controller named DocumentController having a port request at "http://localhost/api/content" and using default route and route data 'controller' having a value of 'document'". It indeed reads better and is easy to repeat in multiple tests with changing request types, routes and route data. 

But what is going on here. 

Lets analyse this code line by line. On first line we call  

Build.Controller<DocumentController>()

Build is a static class having a method Controller<T>. This gives us an instance of a class called ControllerBuilder<T>. Here is the code for both of these classes

public static class Build
    {
        public static ControllerBuilder<T> Controller<T>() where T : ApiController, new()
        {
            return new ControllerBuilder<T>();
        }
    }

public class ControllerBuilder<T> where T: ApiController, new()
    {
        private RequestBuilder requestBuilder;
        private RouteBuilder routeBuilder;

        public RequestBuilder PostRequest()
        {
            requestBuilder = new RequestBuilder(HttpMethod.Post);
            return requestBuilder;
        }

        public RouteBuilder UsingRoute(string name, string value)
        {
            routeBuilder = new RouteBuilder(name, value);
            return routeBuilder;
        }

        public RouteBuilder UsingDefaultRoute()
        {
            return UsingRoute("DefaultApi", "api/{controller}/{id}");
        }

        public T Having(Action<ControllerBuilder<T>> builder)
        {
            builder(this);
            return Build();
        }

        private T Build()
        {
            var configuration = new HttpConfiguration();
            var routeData = routeBuilder.BuildFor(configuration);
            var request = requestBuilder.Build();

            var controller = new T
            {
                ControllerContext = new HttpControllerContext(configuration, routeData, request),
                Request = request
            };
            controller.Request.Properties[HttpPropertyKeys.HttpConfigurationKey] = configuration;

            return controller;
        }
    }

There is a lot going on here..!!
 Actually not, it is same piece of code that we saw in the beginning in private method Build of ControllerBuilder class. All other methods are there in order to provide a fluent way of configuring and setting various pieces of information required to build the controller. There are two other classes referred here, namely RequestBuilder and RouteBuilder. They too are simple classes with methods that let you configure a HttpRequestMessage and route definitions in a fluent way. Here is how those classes look

public class RequestBuilder
    {
        private readonly HttpMethod httpMethod;
        private string requestUrl;

        public RequestBuilder(HttpMethod httpMethod)
        {
            this.httpMethod = httpMethod;
        }

        public RequestBuilder At(string url)
        {
            requestUrl = url;
            return this;
        }

        public HttpRequestMessage Build()
        {
            return new HttpRequestMessage(httpMethod, requestUrl);
        }
    }

public class RouteBuilder
    {
        private readonly string routeName;
        private readonly string routeValue;
        private readonly HttpRouteValueDictionary routeDataCollection = new HttpRouteValueDictionary();

        public RouteBuilder(string routeName, string routeValue)
        {
            this.routeName = routeName;
            this.routeValue = routeValue;
        }

        public RouteBuilder HavingRouteData(string name, string value)
        {
            routeDataCollection.Add(name, value);
            return this;
        }

        public IHttpRouteData BuildFor(HttpConfiguration config)
        {
            var route = config.Routes.MapHttpRoute(routeName, routeValue);
            return new HttpRouteData(route, routeDataCollection);
        }
    }

As you can see there is nothing complex in these classes, just a few methods that accept some parameters required to configure the object they are building and a method that actually builds the object.

In closing

Fluent interfaces, in my opinion, come in handy where an operation/task consists of series of steps that when written in traditional style feel unrelated. This is mostly found in the set up phase of actual operation. Hope you find this little tip helpful.

These files are also available for download as a nuget package named "FluentTestingUtils". If you are new to nuget then navigate to pacckage page on nuget to know more

Update

I just published an update to this package as I found out a tricky situation with using these classes. You can read the details here. I hope to push more and more updates in future.

Service Locator vs Dependency Injection

We recently introduced IoC container (Autofac) in our project. And we liked it, we liked it so much that we have started using in more than a few places now. But soon I realized a trap we are falling into, the trap of "Service Locator" pattern. Before I get into nitty-gritty of this trap, let's briefly talk about service locator vs dependency injection

There are two patterns to implement inversion of control. The code snippet below shows the most common and easy pattern - the service locator

public class CreateCusutomerCommand
{
    private Customer customer;

    public CreateCusutomerCommand(Customer customer)
    {
        this.customer = customer;
    }

    public void Execute()
    {
        var customerPersister = Container.Resolve<IPersistCustomer>();
        customerPersister.Persist(customer);
    }
}

Here we are using a static Container instance to resolve an instance of IPersistCustomer interface. This pattern slightly modified in the code below become a dependency injection pattern.

public class CreateCusutomerCommand
{
    private Customer customer;

    private IPersistCustomer customerPersister;

    public CreateCusutomerCommand(Customer customer, IPersistCustomer customerPersister)
    {
        this.customer = customer;
        this.customerPersister = customerPersister;
    }
    public void Execute()
    {
        customerPersister.Persist(customer);
    }
}

Here we are not using a container to resolve IPersistContainer, instead, we are accepting an instance through constructor. We are declaring IPersistContainer as a dependency and enforcing it be injected through constructor. So why am I saying that service locator pattern is a trap? There are a few reasons that I have experienced myself

1. The container API (call to container.Resolve<T>()) is referenced all over the places. Container becomes sticky dependency that is difficult to get rid of. 
2. If you are doing TDD and you want to write tests for CreateCustomerCommand class in the first example then your tests must have the knowledge of the container and what types are registered in the container. 
3. Tests may have a need to change the behaviour offered by the registered types in the container. 
4. The only way to do that would be create proxy types and register them again from the tests. 
5. One of the above would lead to your test project being dependent on container assemblies

If you use dependency injection pattern and wire it up properly (e.g. If I'm building an MVC project and using Autofac, I would use Autofac MVC integration and delegate the controller creation to autofac) then you would rarely need to resolve a type yourself manually. The container API calls are not littered in you code base. 

The most interesting part comes when you are writing tests. It's very easy to write tests against class in the second example. I know that I need to pass in some implementation of IPersistCustomer interface. I can just mock it and there is no other setup required. 
Life has become so easy with this change.