rickardnilsson.net is a weblog and the online home of web developer and father of three, Rickard Nilsson... More
Rickard blogs about creating software solutions using ASP.NET and agile practices.
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 in terms of dynamism and 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:
After I posted my Code Kata Cast I received some feedback regarding the ReSharper templates I use to speed up my coding. I decided to share them with the public (like so many before me) in hope that others may benefit from them, as I do.
rickardn-resharper-templates.zip (1,44 kb)
After you’ve downloaded the zip-file and unpacked it, open Visual Studio and the ReSharper Templates Explorer: Menu –> ReSharper –> Live Templates…
Click on Import… as the screen shot below shows, and find the file “rickardn-resharper-live-templates.xml”
Then click the “File Templates” tab and repeat the procedure for the “rickardn-resharper-file-templates.xml” file.
Good luck with your katas!
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