Unit Testing WebApi with custom ModelBinders

Today I started working on a new WebApi application that uses Windows Authentication. I need the current user to check group access and load features that are available for the current user.

While working on this I used ModelBinders to improve the testability of my code. While searching for a solution I also encountered some differences between model binders in WebApi and MVC. In this blog I want to quickly show how to use a ModelBinder in WebApi to improve testability.

The basic way

Off course you can always do something like this:

public List<Application> GetApplications()
{
    IPrincipal currentUser = User;
    ....
}

The base ApiController exposes a User property that returns the current IPrincipal. This Principal can be used to check the current user and the roles they are in.

Let’s say you want to test this action method. You want to check for certain combinations of Users/Groups and make sure the correct features are loaded. So we need to find a way to change the User property of the ApiController base class. This property doesn’t expose a setter so we can’t change it directly.

Luckily for us we have access to the source code of the ApiController:

public abstract class ApiController : IHttpController, IDisposable
{

    .....

    public IPrincipal User
    {
        get { return Thread.CurrentPrincipal; }
    }

    ....

  }

So the only thing the User property is doing, is checking the Thread.CurrentPrincipal. And Thread.CurrentPrincipal does have a setter property!

In our test code we could switch the current user with the following code:

var principal = new GenericPrincipal(new GenericIdentity("foo"), new string\[\] { });
Thread.CurrentPrincipal = principal;

After that we can call our ApiController and execute tests against the principal we just setup.

But is this really the way to go? Is this nice testable code? Will it be clear for you one year from now? Will it be clear to your colleague?

Refactoring for testability

Code should ask for what it needs. All access to ‘global data’ should be avoided.

Why? Because that way it’s much easier to see what a function needs and on which data it executes.

Things like statics and singletons are considered global data. A user of your class has no way of knowing which data you access and what actions you start executing when you use statics or singletons.

In our case, the Thread.CurrentPrincipal is such a problem. What if we could change your action method to the following:

public List<Application> GetApplications(IPrincipal user)
{
    ....
}

The method now clearly states what it needs. There are no hidden surprises and users of your class can easily see what they need to test it.

(See also the following blog posts: Unit Testing, hell or heaven? and TDDing in Visual Studio 2012)

To make this method overload work in ASP.NET WebApi we can use a functionality called ModelBinding.

A ModelBinder for IPrincipal

ModelBinding is the process in which the ASP.NET framework checks how it can populate the parameters of your method. It looks trough things like Form fields, JSON post data, Route data, Querystring parameters and even posted files.

The frameworks model bindings capabilities can be easily extended with your own ModelBinders which can vastly improve your code.

After looking around on the internet I found the following blog post by Scott Hanselman: IPrincipal (User) ModelBinder in ASP.NET MVC for easier testing.

ASP.NET WebApi however needs some changes to this code:

using System;
using System.Web.Http;
using System.Web.Http.Controllers;
using System.Web.Http.ModelBinding;
  
namespace MyApp.ModelBinder
{
    public class PrincipalModelBinder : IModelBinder
    {
        public bool BindModel(HttpActionContext actionContext, ModelBindingContext bindingContext)
        {
            if (actionContext == null)
            {
                throw new ArgumentNullException("actionContext");
            }

            if (bindingContext == null)
            {
                throw new ArgumentNullException("bindingContext");
            }

            var apiController = actionContext.ControllerContext.Controller as ApiController;

            if (apiController == null)
            {
                throw new InvalidOperationException("Cannot determine current  user. Controller is not of type ApiController");
            }

            bindingContext.Model = apiController.User;
            return true;
        }
    }
}

The Controller is cast to an ApiController and then bindingContext.Model is set to the current user.
If you then register your new ModelBinder in your WepApiConfig everything is good to go:

config.BindParameter(typeof(IPrincipal), new PrincipalModelBinder());

From your unit test you can now easily pass the correct principal to your method. And when running your application in the browser, WebApi will use your custom model binder to get a value for IPrincipal and pass that to your method.

ModelBinding is one of the extension points of both MVC and WebApi that can really help you in creating better testable code.

Why have you used ModelBinding? Have you found another way to make code like this more testable? Or maybe you have a totally different opinion? Please leave a comment!