Saturday, November 16, 2013

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/

Wednesday, November 6, 2013

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. 

Sunday, October 27, 2013

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

Saturday, October 26, 2013

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.