Rickard Nilsson is a software architect, developer, craftsman, agile enthusiast, and father of three... More
Rickard blogs about crafting software using .NET tooling and solid, development practices.
I’ve been working extensively with ServiceStack lately and I really like what they’ve done. As it contains the full stack for building HTTP based services from text serializers to development tools to a micro ORM it’s very easy to fall into the pit of success. I don’t mind picking and choosing these things for my self, however it’s nice that is doesn’t require any brain power making choices. Plus you can always be assured that the tools you get in the box is quick to get started with, and has all the performance you’ll ever need. They might be too simplistic four your needs but then it’s nice to know that its usually very simple to replace them with something else.
Let me tell you a story.
I was cruising along doing my thing, test-driving my code and was feeling pretty good about myself. I was hitting a very high code coverage as I was only writing a little bit of test code, a little bit of production code, and refactored as I went along. Now, I hit a pain point which showed itself to be very difficult to get under test. It was the few lines where I actually called the database through OrmLite’s extension methods.
OrmLite is a micro ORM and is part of the basic ServiceStack package. It is a set of extension methods on top of System.Data.IDbConnection which makes it very easy to use at the same time giving you direct access to the underlying APIs. It consists of operations like Insert<T>, Update<T>, Select<T> etc. and is really easy to get started with.
Anyway, as OrmLite is only extension methods on IDbConnection I though it’d be simple as cake to fake it out such that I could get my database calls under test as well.
Turns out it was way more difficult than I had anticipated. After a little while I gave up and left a total of four lines uncovered (one line per entity).
The other day I was looking through the ServiceStack documentation after something totally unrelated and stopped at a couple of lines that caught my attention.
// Use in-memory Sqlite DB instead
var dbFactory = new OrmLiteConnectionFactory(
":memory:", false, SqliteOrmLiteDialectProvider.Instance);
So, it was possible to use an in memory database instance instead of the SQL Server provider I was using in production. Very interesting. Could I utilize this in my unit tests to get that last mile?
Lets see. I quickly wrote a little unit test to try it out.
1: [TestClass]
2: public class EntityRepositoryTests
3: {
4: Entity expectedEntity;
5:
6: [TestMethod]
7: public void GetAll_All_ReturnsAllFromDatabase()
8: {
9: var dbFactory = new OrmLiteConnectionFactory(
10: connectionString: ":memory:",
11: autoDisposeConnection: false,
12: dialectProvider: SqliteOrmLiteDialectProvider.Instance);
13:
14: using (var db = dbFactory.OpenDbConnection())
15: {
16: db.CreateTable<Entity>();
17: expectedEntity = new Entity
18: {
19: Id = 1,
20: Name = "foo"
21: };
22: db.Insert(expectedEntity);
23: }
24:
25: var repository = new EntityRepository(dbFactory);
26:
27: var result = repository.GetAll().ToList();
28:
29: Assert.That(result, Is.EqualTo(new [] { expectedEntity }));
30: }
31: }
Sqlite is not included in the standard ServiceStack package, however it’s simply a matter of running a command in the Nuget Package Manager Console:
1: PM> Install-Package ServiceStack.OrmLite.Sqlite32
for the test project and SqliteOrmLiteDialectProvider lights up.
When this was done NCrunch automagically picked it up and everything turned green immediately. Nice!
Running the test with MSTest was a little trickier as it turned out. Sqlite drops an interop dll in the test project as a resource which MSTest couldn’t pick up. To get that to work I needed to add the dll as a deployment file in the local test settings. When I did that, the whole thing even ran in the continuous integration build in TeamCity.
Awesome day at work. Hope you’ve found this tip useful. Cheers!
I’ve previously blogged about how we practice Continuous Integration with TeamCity at Ninetech but some time has passed and now it is time for an update.
After an upgrade to TFS2010 we started to use its build system for some of our development projects but since many of them lacked automated testing the usage didn’t really take off. To change this, an internship project was started where students from Karlstad’s university would create some way to highlight the opportunity to get immediate feedback for team members as well as stake holders and other interested at our company.
The result of the project can be seen below. It is our TFS TV placed on the wall of our developer room such that all developers, as well as any one who passes by, can see the current status of our projects. It is a WPF app which cycles through all of our TFS build configurations, gathers the latest test data, goes to our web site and fetches the photo of the latest committer, and displays it all on the 42” plasma screen.
The effect we’re after is to raise the level of awareness and usage of continuous integration and automated testing by providing immediate feedback to all teams when something fails and as well as a quick way of keeping track of a project through some of its metrics.
As seen below no one can miss if a build is failing which makes everybody who commits to a project on the screen extra careful not to commit code which is untested or brakes the build in any way.
What’s next? As we’re using a mix of source control systems (TFS, Git, Hg, SVN) and continuous integration platforms (TFS, TeamCity) the plan is to support TeamCity as well and maybe find a way to release it into the wild. We’ll se what happens.
TDD Katas has become very popular in a small segment of the development community and we call our selves software craftsmen. We are passionate about software development as a craft and engage in different activities to better our selves and our peers.
My first kata cast, for instance, has been viewed close to 10k times on Vimeo since its publication. Much of the attention is of course due to Roy Osherove linking to my blog post from his TDD Kata 1 page. This time Roy initiated a sequel, meant to introduce interaction based testing using mocks and possibly stubs, and continue the teaching process of TDD and unit testing practices.
The following screen cast covers the entire kata in .NET, complete with Osherove’s three steps as well as manual UI testing at the end.
For best viewing experience I recommend watching it on Vimeo.com in HD
String Calculator TDD Kata 2 - Interactions from Rickard Nilsson on Vimeo.
The tools I use are Visual Studio, ReSharper, TestDriven.NET, Moq for mocking, and NUnit.
The code and Visual Studio solution for the finished Kata can be downloaded from GitHub:
Download source
As Osherove mentions in his instructions, this kata is not as simple as the first part, nor as simple as most katas out there. The reason is the element of interaction based unit testing involved, which is quite difficult to wrap you mind around, and it took quite a while to get the steps right. I thought I should share my path to the kata in its present form for others to learn from and comment on.
Step 1. Everytime you call Add(string) it also outputs the number result of the calculation in a new line to the terminal or console. (remember to try and do this test first!)
As I did this test first I started out pretty much as how it ended up in the cast. However, after a while I tried to take a step back and see if there were any smells in the code I had not yet discovered.
I found that I didn’t really like the mixed responsibilities that the Calculator class got when I introduced writing to the console. This could be seen as a logging feature and thus a perfect candidate to become an aspect (in AOP). I started playing around with PostSharp and ended up with the following solution which is quite clean.
[Serializable] public class OutputAttribute : OnMethodBoundaryAspect { [NonSerialized] private IContainer container;
public override void OnExit(MethodExecutionArgs args) { var console = container.Resolve<IConsole>(); console.WriteLine(args.ReturnValue.ToString()); }
[OnDeserialized] public void OnDeserialized(StreamingContext context) { container = ContainerFactory.Current; } }
Which, at most, leaves the mark of a custom attribute in the Calculator class:
public class Calculator { [Output] public int Add(string value) { ... } }
The problem with this solution is the way PostSharp works. It does all its magic as a post compilation step so everything is pretty much static. This is a problem in a testing scenario when we need to inject the mocked console in this case, hence the smelly ContainerFactory.Current stuff.
Another problem with this solution is that in part three, the console app, we need to disable or override what is outputed. This ends up becoming a static mess which did not feel right at all. If you have another view on this please leave a comment.
Step 2. Create a program (test first)that uses string calculator, which the user can invoke through the terminal/console by calling “scalc ‘1,2,3’” and will output the following line before exiting: “The result is 6”
For step 2 and 3 I thought a bit about refactoring to a UI design pattern like MVP, MVC or MVVM but finally decided to drop it, mainly because I didn’t know any framework like that for console applications. If the application grows I think this is the right way to go, but for the known requirements it’s an overkill, especially considering how small the solution is.
Step 3. Instead of exiting after the first result, the program will ask the user for“another input please” and print the result of the new user input out as well, until the user gives no input and just presses enter. in that case it will exit.
I played around a bit with SpecFlow, which has ha free form Given/When/Then specification syntax, on the later part of the kata. However, I felt that I lost velocity so I dropped it as well. Maybe, if I had some way of conducting complete acceptance testing through a real console, I would have pursued this further. It was simply too much to write, for example:
Scenario: Prompt user for another input Given a new string calculator And the user has entered: a valid input When the program has outputed The result is 1 Then the user is prompted for another input Scenario: Quit on empty input Given a new string calculator And the user is prompted for another input When the user hits enter Then the program should exit
Scenario: Prompt user for another input
Given a new string calculator
And the user has entered: a valid input
When the program has outputed The result is 1
Then the user is prompted for another input
Scenario: Quit on empty input
And the user is prompted for another input
When the user hits enter
Then the program should exit
Figure 3. SpecFlow Feature specification for the console app If you have any thoughts, comments, suggestions, or any other feedback please leave them below or ping me on twitter.
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:
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.
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.
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.
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.
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.
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.
Disclaimer: The slides has been cleaned from all customer references in the internal material.
Are you new to the concept of code katas? Read my previous blog post and watch me perform the String Calculator Kata.
In my never ending goal of self improvement in the techniques and tools I use I’ve been practicing a version of the Prime Factors Kata for a while.
The Prime Factors Kata, initially sparked by the infamous Uncle Bob Martin, is about finding an arbitrary number’s prime factors. In the cast I show how my TDD practice has evolved into a flavor of BDD, mainly to reduce duplication in the unit tests. I also show off the awesome power of my current toolset which includes the Visual Studio 2010 and the latest versions of ReSharper, TestDriven.NET, NUnit and NBehave.
Though my performance is not yet perfected I want to put it out there because I feel there are no C# version that can really match the Ruby version in elegance and wit. This is my attempt to show what you can do with the C# language when you know the frameworks really well.
Please leave comments and/or suggestions below or record your own kata session in response.
Prime Factors Kata in C# from Rickard Nilsson on Vimeo.
If you are new to the Prime Factors Kata, code katas in general, or TDD for that matter, you may find the steps I take unnecessary or weird. You may want to watch the annotated version in which Uncle Bob explains why each step is taken and why they are taken in that order.
Many have recorded there own versions of the Prime Factors Kata which all inspired me in the way I practice it. The cast that inspired me the most is
there are also a few other C# casts worth watching for comparison by:
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.
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:
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:
public partial class ServerUsageExamplePage : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { //... Server.MapPath("...");
//... } }
In our unit test we want to be able to replace the call to Server.MapPath() such that
The following test method will fake the call to Server.MapPath() and assert that it was actually called by the method under test:
[TestMethod] [HostType("Moles")] public void MapPath_WhenCalledWithProperContext_ShouldInvokeServerMethod() { // Arrange var mapPathWasCalled = false; MHttpContext.CurrentGet = () => new MHttpContext { ServerGet = () => new MHttpServerUtility { MapPathString = path => { mapPathWasCalled = true; return string.Empty; } } };
// Act var page= new ServerUsageExamplePage(); page.Page_Load(this, EventArgs.Empty);
// Assert Assert.IsTrue(mapPathWasCalled); }
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:
Finally, to be able to execute the method under test (Page_Load), we need to change its accessibility from protected to public.
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:
// change the value of DateTime.Now MDateTime.NowGet = () => new DateTime(2000,1,1); if (DateTime.Now == new DateTime(2000,1,1)) throw new Y2KBugException();
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
Here is a video that introduces Moles:
Update!
Download sample project MvcWithUnity.VS2010.zip (727,52 kb)
Download sample project MvcWithUnity.VS2008.zip (546,33 kb)
Update! This still apply in ASP.NET MVC 2 and Unity 2.0. Read more here...
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.
[TestMethod] public void Post_PostWithSlugExists_ReturnsResultWithPostAsModel() { controllerContext.RouteData.Values.Add("slug", ValidSlug); var expected = MockRepository.GenerateStub<IBlogPost>(); var blogPosts = new[] {expected}; blogPostService.Expect(s => s.GetPostWhereSlugEquals(slug)) .Repeat.AtLeastOnce() .Return(blogPosts); var controller = CreateController();
var result = (ViewResult) controller.Post(); Assert.AreEqual(expected, result.ViewData.Model); }
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.
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.
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.
public class UnityControllerFactory : DefaultControllerFactory { private readonly IUnityContainer container;
public UnityControllerFactory(IUnityContainer container) { this.container = container; }
protected override IController GetControllerInstance(Type controllerType) { return container.Resolve(controllerType) as IController; } }
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.
// in Global.asax.cs protected void Application_Start() { RegisterRoutes(RouteTable.Routes);
var container = new UnityContainer(); var controllerFactory = new UnityControllerFactory(container); ControllerBuilder.Current.SetControllerFactory(controllerFactory); }
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.
public class PostController : Controller { private readonly IBlogPostService blogPostService;
public PostController(IBlogPostService blogPostService) { this.blogPostService = blogPostService; }
public ActionResult Post() { var slug = GetSlug(); var post = blogPostService.GetPostWhereSlugEquals(slug); return View(post); }
private string GetSlug() { return RouteData.GetRequiredString("slug"); } }
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>
<%@ 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>
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.
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.
Much of the legacy ASP.NET code I’ve seen is littered with calls to methods on the HttpServerUtility class,
Server.MapPath(…)
Why, if your suite has thousands of tests and many calls IO or datebases, the tests will run slowly, and the developers on the team won’t run them as often. Ultimately, you may loose your investment in automated testing because it isn’t providing the promised feedback.
If the code behind code calls Server.MapPath() it is actually calling the Server property on the Page base class which returns HttpContext.Current.Server. This is an instance of the HttpServerUtility class, which is sealed and thus pretty impossible to fake out*.
In the namespace System.Web.Abstractions, which is part of ASP.NET 3.5, lives an abstraction of the HttpServerUtility, called HttpServerUtilityBase. It has a concrete implementation named HttpServerUtilityWrapper that takes an HttpServerUtility instance as a constructor parameter, as follows:
public sealed class HttpServerUtility { // ... }
public abstract class HttpServerUtilityBase { // ... }
public class HttpServerUtilityWrapper : System.Web.HttpServerUtilityBase { public HttpServerUtilityWrapper(HttpServerUtility httpServerUtility) {} // ... }
By leveraging a simple form of dependency injection we can preserve the old code as a first step of refactoring, and using an overloaded constructor to inject the fake object in our unit test.
public class Presenter { private HttpServerUtilityBase Server; public Presenter(HttpServerUtilityBase httpServerUtility) { Server = httpServerUtility; } public Presenter() { Server = new HttpServerUtilityWrapper(HttpContext.Current.Server); } public void PageLoad() { var path = Server.MapPath(…) } }
Now, in a unit test for the Presenter class we can inject a fake server utility, which won’t call any IO.
[Test] public void PageLoad_WhenCalled_ExpectedBehavior() { var fakeServerUtility = new HttpServerUtilityFake(); // implemented in the test suite var presenter = new Presenter(fakeServerUtility); presenter.PageLoad(); // Assert expected behavior }
Instead of implementing your own fake you can easily use your preferred isolation (mocking) framework of choice.
The goal is to isolate the class under test from all of its dependencies, weather they call IO, a database, a third party component, or even statics or touch static state. The point is that we want to assert that the class under test behaves as expected, not how the underlying framework behaves.
By leveraging the System.Web.Abstractions namespace we can preserve much of the existing ASP.NET code while covering it with tests.
_________ * Unless using TypeMock Isolator