Rickard Nilsson

In my current project we have adopted the Continuous Integration process and its key practices, some of which we’ve used in previous projects, but not all at once.

The project technology stack looks like this:

• ASP.NET 4 (MVC)
• Team Foundation Server 2008
• Team City Professional
• IIS 7
• IIS Web Deploy

Single Source Repository

We have been using Team Foundation Server since version 2005 and all new and ongoing projects use it, however, Continuous Integration takes source control to another level and require us to put more stuff in there than we are use to. For example, all versions of web.config is stored and version controlled through the Web.config Transformations in ASP.NET 4. This gives us easy access and great control over the different configuration setups we use in all our environments.

Automated build

Compiling, building and running unit tests is something we’ve been doing for years in Visual Studio, but when we had to do the same in an automated Continuous Integration process we could not rely on the build scripts generated by Visual Studio (e.g. all .csproj-files) alone but had to learn MSBuild our selves. It turned out to be a very good thing. Build scripting languages like MSBuild give you the power to do pretty much anything you need to build your software in an automated fashion, and it is the core building block for Continuous Integration and development automation in general.

We have for instance used MSBuild scripts to automate deployment to multiple sites and to generate code coverage reports publishable in Team City.

The build is self testing

In my opinion, to be able to automatically verify that features we implemented earlier continue to work throughout the project and beyond, is the single most valuable practice in our profession. Think of how many hours you spend testing the same thing over and over, if you don’t have tests. Start automating testing today, and you do not want to go back.

The automated testing part of Continuous Integration is what really makes it all worth it. Plus, the rapid integration feedback act as a motivator for keeping the test coverage high and not falling for the temptation to get lazy and skip tests. If the coverage drops you can not be as confident that the code is healthy even though the build passed.

My highest priority is unit tests, followed by integration tests. I’ve started to look at acceptance testing and I plan to integrate that in our CI process later.

Everyone commits every day

A short check in-cycle is key to getting value from Continuous Integration. In practice this means that I try to check in as soon as I can describe the change as a check in comment. If I have a hard time describing the change, it’s probably a sign I have done too much, and should have checked in earlier.

An integration machine builds on every commit

We chose to use Team City on our build servers because it was so easy to get started. In my first attempt I installed Team City on my dev machine, created a new project in the web user interface, connected the project to TFS, and hooked it up to build using the Visual Studio .sln-file. It took less than 20 min to get a full Continuous Integration build running on every check in. But it doesn’t stop there, Team City supports every imaginable tool for build automation and is fully extensible.

Automated deployment

In previous projects I’ve always felt impeded by a slow and error prone deployment process. A consequence is often that deployment can only be performed by one individual from his or her machine. In my current project I focused hard on getting it automated from the beginning. We have multiple sites that all need to get deployed at once so we’ve set up a build configuration in Team City where anyone on the project at any time can at the click of a button, get the latest from source control, run the check in-tests, and deploy to all servers. Usually this takes no more than a minute.

The secret behind this is the new IIS Web Deployment Tool from Microsoft (also known as MS Deploy). It enables a user without administrator privileges to synchronize the content of a site in IIS. Synchronization is key to making the deployment go super fast since we never need to do a full transfer, only the changes are pushed.

In the following example I will show how easy it is to isolate your client code from ASP.NET code, using the Moles Isolation Framework, in order to test that your code performs as intended.

The example should not be seen as an encouragement to use bad design. On the contrary, I urge you to use Moles to get that ugly, old legacy code you’ve got, and put it under test such that you will have the freedom to rip it apart and improve it.

Prerequisites

1. Download and install Moles Isolation Framework for .NET
2. Open your Solution
3. Create a test project by doing File > Add > New project > Test > Test Project
4. Add the following references
   1. Microsoft.Moles.Framework
      %MolesPath%\PublicAssemblies\Microsoft.Moles.Framework.dll
   2. System.Web
5. On the test project: choose Add > New Item…
6. Choose the Moles template “Moles and Stubs for Testing”
7. Name it “System.Web.moles”

Now Moles will generate an assembly with mocks and stubs of the target assembly (System.Web) and add it to the test project. Your references should look like this:

Class under test

Now you are ready to start writing tests. First we take a look at our sample application. It is a simple ASPX-page which calls Server.MapPath() in the Page_Load method:

In our unit test we want to be able to replace the call to Server.MapPath() such that

1. We won’t get an NullReferenceException
2. We can control what is returned

The following test method will fake the call to Server.MapPath() and assert that it was actually called by the method under test:

Under the covers

To accomplish this we need to understand what is going on. “Server” is an instance property on the System.Web.UI.Page class which eventually will invoke the HttpContext.Current.Server property. Thus, to fake the method call we need to fake several things:

1. Static property HttpContext.Current
2. Instance property Server on HttpContext
3. Instance method MapPath on HttpServerUtility

Access modifier

Finally, to be able to execute the method under test (Page_Load), we need to change its accessibility from protected to public.

Summary

I've shown how easy it is to get started covering your ASP.NET codebehinds with unit tests utilizing Moles Isolation Framework. Please leave feedback and any questions you might have. Good luck testing!

Moles is a new framework from Microsoft Research for isolating objects in unit tests. With the framework you create test stubs by using delegates and you can route any .NET method you want, including non-virtual and static methods in sealed classes. In addition, the framework is free, making it a major competitor to TypeMock Isolator that has been alone on this functionality for a long time.

Moles automatically generates stubs for all classes in one assembly. Here is an example of how easy it is to change the behavior of the static DateTime.Now property:

For SharePoint

Mole’s strength to fake and reroute static methods and the like makes it a very powerful tool for isolating and unit testing code developed for SharePoint. Microsoft Research has a whitepaper that describes how to get started:

Unit Testing SharePoint with Microsoft Foundation Pex and Moles

Introduction

Here is a video that introduces Moles:

Enabling truly easy testability with ASP.NET MVC Controllers requires a Dependency Injection container. This post is about showing a more real life example of combining Unity with ASP.NET MVC Controllers than the standard demo. Unity is the IoC Container from Microsoft Patterns & Practices and ships as a part of Enterprise Library as well as a stand alone on Codeplex.

We start with the unit test which drives the design of the controller.

Even though the test becomes a bit verbose it clearly states the intent of the controller’s Post method; given the right slug, a result is returned with a blog post as model.

Dependency Injection in ASP.NET MVC

In ASP.NET MVC every request starts in a controller which uses a set of dependencies to do its job. When we have applied Inversion of Control we can inject all of the controller’s dependencies either as a constructor argument or as a property setter. To fully take advantage of this technique we want the dependencies to be automatically injected without creating any of them in overloaded constructors or something like that. This is where the Controller Factory in ASP.NET MVC comes into play.

Controller Factory

In the System.Web.Mvc namespace lives the IControllerFactory which implementation is used by the framework to create controller instances. We can use this to swap out the default one and replace it with our own controller factory which uses Unity to create controllers instead.

Instead of implementing all of the IControllerFactory functionallity we can extend the System.Web.Mvc.DefaultControllerFactory and only override what we need.

In the Global.asax, called MvcApplication in ASP.NET MVC by default, we create our Unity container and tells the MVC framework to use our UnityControllerFactory instead of the default one.

PostController

To illustrate why this is so powerful we will implement a controller that handles requests for blog posts, such as the one you’re reading right now. For this example the controller only handles requests for single blog posts using the post’s slug as identity. A slug is the post’s title made url friendly (e.g. "Dependency-injection-in-ASPNET-MVC-with-Unity-IoC-Container” for this post). The PostController has a dependency on an IBlogPostService which it uses to lookup the blog post to send to the view.

Strongly-typed views

The Post action returns an ActionResult with the post a the model. We can use strongly-typed views to get intellisense in the aspx-file.

<%@ Page /*...*/ Inherits="ViewPage<IBlogPost>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">

    <%=Model.Title %>

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2><%=Model.Title %></h2>

    <p>

        <%=Model.Body %>

    </p>

    <p><%=Html.PostActionLink("Permalink", Model) %></p>

    <p><a href="/2009/10/10/fail">fail link</a></p>

</asp:Content>

Notice how the view inherits from ViewPage<IBlogPost> which is key to make the model type of IBlogPost. Then we can use the Post properties to render the blog post in the view.

Conclusion

Combining ASP.NET MVC with Unity or your IoC Container of choice makes your controllers much more easily testable. You only state your classes dependencies as constructor parameters or properties and the container will do the wiring for you. The gives you time to focus on the program logic and the interaction between its components.