Horsdal

Repositories and Single Responsibility from the Trenches

2012-01-30T23:18:00.001+01:00

In a project I'm involved with we've done what I suspect lots and lots of projects do. We've used the repository pattern to encapsulate database adds, queries and deletes. We have one such repository per entity type. That worked well for me in earlier projects. But in this case several of the repositories have become somewhat unfocused. None of them are big hairy monsters, but the different public methods really don't have much in common except the fact that they mainly act on the same entity type. In other words cohesion is low. Let me exemplify (anonymized just as the rest of the code in this post):

    9 public interface IDeviceRepository

   10 {

   11   TDeviceType Get<TDeviceType>(long id) where TDeviceType : Device;

   12   TDeviceType FindByControllerIdentifier<TDeviceType>(string controllerIdentifer)

   13       where TDeviceType : Device;

   15   IList<TDeviceType> GetAll<TDeviceType>(int offset, int max,

   16       DateTimeOffset? createdAfter = null, DateTimeOffset? updatedAfter = null,

   17       DateTimeOffset? disconnectedAfter = null)

   18       where TDeviceType : Device;

   20   int Count<TDeviceType>(DateTimeOffset? createdAfter = null,

   21       DateTimeOffset? updatedAfter = null, DateTimeOffset? disconnectedAfter = null)

   22     where TDeviceType: Device;

   24   void Add<TDeviceType>(TDeviceType device) where TDeviceType : Device;

   25   IList<TDeviceType> GetAll<TDeviceType>() where TDeviceType : Device;

   26   IList<TDeviceType> GetAll<TDeviceType>(long[] deviceIds) where TDeviceType : Device;

   27   IList<TDeviceType> FindByControllerIdentifiers<TDeviceType>(string[] controllerIdentifiers)

   28       where TDeviceType : Device;

   29   IList<NodeDevice> FindNodesDevicesForRootDevice(string controllerIdentifier,

   30       bool active = false);

   31   ICollection<NodeDevice> FindNodeDevicesForRootDevice(long rootDeviceId, bool active = false);

   33   IEnumerable<DeviceLink> GetTopology<T>(long id, bool active) where T : Device;

   34   DeviceLink GetDeviceLink(string controllerIdentifierA, string controllerIdentifierB);

   35   DeviceLink GetDeviceLink(long id);

   37   void AddDeviceLink(DeviceLink link);

   39   IList<Route> FindRoutesByDeviceLink(DeviceLink deviceLink);

   40   void Delete(Device device);

   41 }

This doesn't look like the interface of a class that has only one reason to change - i.e. it violates the single responsibility principle (SRP). This is in part because it in fact does not only act on one entity type but on a hierarchy of entity types; device is a base class and the are a handful of concrete types of devices. The obvious solution to that, is to move away from a repository for the base class to a number of repositories for the concrete entities - but that's where we came from. That's a route that led to duplicated code, which led to abstracting into a common device repository, so we did not want to go back down that route again.

Taking Single Responsibility Seriously

The solution we've come up with is - at it's core - simply to take SRP seriously: We want classes that do not do a bunch of database related operations around a type of enity. We want classes that does just one such operation. Take the Delete method on the interface above. That seems innocent enough, but it turns out that the implemetation is a bit complicated: There are a number of relations that need to be untied, and there is some cascading to take care of before the device can be deleted from the database. As a colleague commented: "It looks like a bad stored proc, written in C#". We decided to view that delete operation as "one thing", and decided it justified a class of its own:

   11 public class DeleteDeviceRequest : NHibernateWriteRequest

   12 {

   13   private readonly Device device;

   15   public DeleteDeviceRequest(Device device)

   16   {

   17     this.device = device;

   18   }

   20   protected override void DoExecute()

   21   {

   22     var links =

   23       Session.QueryOver<DeviceLinkReference>().Where(x => x.ControllerIdentifier == device.ControllerIdentifier).

   24         List();

   26     links.ForEach(x => x.Device = null);

   28     DeleteStatistics();

   29     new DeleteRoutesWriteRequest(device.Routes).ExecuteWith(DataStore);

   30     DeleteFromGroup();

   31     DeleteFromOrder();

   32     DeleteProfiles();

   33     DataStore.Delete(device);

   34   }

   36   // more private methods...

The only thing public here is the constructor. The contructor takes all arguments for the delete, so once the object is constructed it completely incapsulates the delete. And - importantly - it is incapable of doing anything else than that particular delete.
How is the delete executed? -Through an execute method on the base class NHibernateWriteRequest.

This swaps the repository pattern for the command pattern plus the template method pattern. But more importantly this swaps a small collection of ever growing repositories for a large collection of small never growing query classes (which, btw, also plays better into the open/closed principle). We've only just started down this path, but I think we'll be happy about it.

There are a few twists I've left out, particularly around making these request objects easy to get at for client code, while maintaining encapsulation and testability. I might revisit those in a future post.

Slides from ANUG talk on Nancy

2011-12-20T21:07:00.000+01:00

I did a talk on Nancy a week ago in the Aarhus -NET User Group. And in my own humble and unbiased opinion it went quite well :-) So I thought I'd share the slides with you - although they probably only make semi-sense without the talk to go along. Anyway here they are; enjoy.

Nancy - A Lightweight .NET Web Framework

View more presentations from Christian Horsdal

Announcing: XmlUnit.Xunit

2011-12-05T21:38:00.001+01:00

I wanted to announce a small library I have on my GitHub: XmlUnit.Xunit, which a library for testing against XML. It's a port of XmlUnit over to use Xunit.NET assertions instead of NUnit assertions, plus an addition of a fluent assertion style. The following is the projects README, and gives you a feel for the purpose of the project. Enjoy.

Intro

XmlUnit.Xunit provides Xunit.NET based assertions tailored to testing XML. The project contains assertions for comparing XML, applying XPath and XSLT expression to XML under test. All assertions come in two flavors: A traditional set of static assertion methods, and a fluent "should" style assertions.

Usage
You grab the source from here, download a build from here or install the NuGet package.

Beware that both the binary in the download tab and the NuGet package may give you assembly conflicts on Xunit.NET. To get around that you need an assmebly rebind of Xunit.NET.

Traditional Assertions
The traditional assertions in XmlUnit.Xunit er all static methods on the class XmlAssertion, and are used like this:

  404 [Fact]

  405 public void AssertStringEqualAndIdenticalToSelf()

  406 {

  407     string control = "<assert>true</assert>";

  408     string test = "<assert>true</assert>";

  409     XmlAssertion.AssertXmlIdentical(control, test);

  410     XmlAssertion.AssertXmlEquals(control, test);

  411 }

  413 private static readonly string MY_SOLAR_SYSTEM =

  414     "<solar-system><planet name='Earth' position='3' supportsLife='yes'/><planet name='Venus' position='4'/></solar-system>";

  416 [Fact]

  417 public void AssertXPathExistsWorksForExistentXPath()

  418 {

  419     XmlAssertion.AssertXPathExists("//planet[@name='Earth']",

  420                                    MY_SOLAR_SYSTEM);

  421 }

  423 [Fact]

  424 public void AssertXPathEvaluatesToWorksForMatchingExpression()

  425 {

  426     XmlAssertion.AssertXPathEvaluatesTo("//planet[@position='3']/@supportsLife",

  427                                         MY_SOLAR_SYSTEM,

  428                                         "yes");

  429 }

  431 [Fact]

  432 public void AssertXslTransformResultsWorksWithStrings()

  433 {

  434     string xslt = XsltTests.IDENTITY_TRANSFORM;

  435     string someXml = "<a><b>c</b><b/></a>";

  436     XmlAssertion.AssertXslTransformResults(xslt, someXml, someXml);

  437 }

Fluent Assertions
The fluent assertions are all extension methods with names starting with Should, and are used like this:

  404 [Fact]

  405 public void AssertStringEqualAndIdenticalToSelf()

  406 {

  407     string control = "<assert>true</assert>";

  408     string test = "<assert>true</assert>";

  409     test.ShouldBeXmlIdenticalTo(control);

  410     test.ShouldBeXmlEqualTo(control);

  411 }

  413 private static readonly string MY_SOLAR_SYSTEM =

  414     "<solar-system><planet name='Earth' position='3' supportsLife='yes'/><planet name='Venus' position='4'/></solar-system>";

  416 [Fact]

  417 public void AssertXPathExestsWorksForXmlInput()

  418 {

  419     new XmlInput(MY_SOLAR_SYSTEM)

  420         .XPath("//planet[@name='Earth']")

  421         .ShouldExist();

  422 }

  424 [Fact]

  425 public void AssertXPathEvaluatesToWorksForMatchingExpression()

  426 {

  427     MY_SOLAR_SYSTEM

  428         .XPath("//planet[@position='3']/@supportsLife")

  429         .ShouldEvaluateTo("yes");

  430 }

  432 [Fact]

  433 public void AssertXPathExistsWorksWithXpathFirstWithXmlInput()

  434 {

  435     var sut = new XmlInput(MY_SOLAR_SYSTEM);

  437     "//planet[@name='Earth']".AppliedTo(sut).ShouldExist();

  438 }

  440 [Fact]

  441 public void AssertXPathEvaluatesToWorksWithXPathFirst()

  442 {

  443     "//planet[@position='3']/@supportsLife"

  444         .AppliedTo(MY_SOLAR_SYSTEM)

  445         .ShouldEvaluateTo("yes");

  446 }

  448 [Fact]

  449 public void AssertXslTransformResultsWorksWithStrings()

  450 {

  451     string xslt = XsltTests.IDENTITY_TRANSFORM;

  452     string someXml = "<a><b>c</b><b/></a>";

  454     someXml.XsltTransformation(xslt).ShouldResultIn(someXml);

  455 }

Further Information
Is probably best gleened off the tests in this project, especially the tests for XmlAssertions and the tests for Should assertions.

Contribute
Please do! Fork, code, send pull request. :-)

Frictionless .NET Web App Development with Nancy Part IV - Hosting

2011-11-08T22:27:00.000+01:00

Continuing my URL shortener sample (part I, II, III), I'll talk about one the things Nancy does quite differently from your average web framework: Nancys concept of hosting. At this point you may be thinking serves or clouds or storage etc, but that's not exactly what Nancy hosting is about.

Nancy Hosting
Nancy hosting is about which stack Nancy runs on top of. Such stacks include ASP.NET, WCF, OWIN, and self hosting. That means that a Nancy app can be run on top of any of those four hosts. You decide. So if you have an existing ASP.NET/IIS setup you can use it to run Nancy, if you have a WCF setup already you can use that.

The two last hosts may need a bit of introduction:

OWIN is Open Web Interface for .NET, which is an attempt to create a common interface between web frameworks and web servers. Currently it's not implemented by that many web servers, but could potentially allow web frameworks and the apps built on them to be move unchanged from one web server to another. One example of an OWIN compliant web server is Kayak, which can run on Mono. Combining these things means that our Nancy app can run on a stack of Nancy/Hosting.OWIN/Kayak/Mono/Linux. In other words a web app written in C# running on OSS all the way down. Who'd have thunk!

Self hosting is another interesting option: Self hosting means running a Nancy app in any .NET or Mono executable. This means that you can slap a web interface onto a desktop app or a windows service. Both of these possiblities are very interesting IMO.

Multiple Hosts - One Code Base
In the URL shortener sample I'd like to use the same application in two different settings: In a stand alone executable (just for kicks) and in ASP.NET stack. To do that I add two projects to my solution, one for each host:

First lets look at bit closer at the ASP.NET hosting project. I.e. the one called ShortUrlWebApp. It's simply an empty web project, as created by Visual Studio, with the Nancy.Hosting.Aspnet NuGet package and a project reference to ShortUrl added. Not one line of code wirtten. The project contains:

The Nancy.Hosting.Aspnet NuGet rewrites the web.config to make Nancy handle all incoming request. Nancy automatically picks up the Bootstrapper and Module in the ShortUrl assembly. That's all there is to running our url shortener on top of ASP.NET.

Second lets loot at the self hosting project. I.e. the one called ShortUrlDesktopApp. It's just a console application with a project reference to ShortUrl and the Nancy.Hosting.Self NuGet added:

In this case a little bit of work is needed in the program.cs - but not much, just instantiating and starting the NancyHost:

    1 namespace ShortUrlDesktopApp

    2 {

    3   using System;

    4   using Nancy.Hosting.Self;

    5   using ShortUrl;

    7   class Program

    8   {

    9     static void Main(string[] args)

   10     {

   11       ShortUrlModule artificiaReference;

   12       var nancyHost = new NancyHost(new Uri("http://localhost:8080/"));

   13       nancyHost.Start();

   15       Console.ReadKey();

   17       nancyHost.Stop();

   18     }

   19   }

   20 }

With this setup we can run the app on ASP.NET of from a console app. There is no difference in the browser and the application code is the same. This - IMO - is very cool indeed.

And the code is still on GitHub.

Frictionless .NET Web App Development with Nancy Part III - Introducing MongoDB

2011-10-24T22:29:00.000+02:00

Continuing the URL shortener sample from thesse post: part I and part II, I'll go from (stupidly) storing the shortened URLs in a static variable, as was the case in the code in part I, to storing the shortened URLs in MongoDB. The reasons for choosing MongoDB for persistence in this sample (compared to the "traditional" NHibernate + SQL Server approach) are:

We will only store and retrieve one document at a time. Those are atomic operations in Mongo, so as far as this sample goes Mongo is fully consistent.
Mongo is simple to setup, and very simple to code against. For instance there is no O/R mapping layer at all.

In summary, Mongo is a nice frictionless option for this sample.

Enough talk, show me the code!

Decoupling interface from persistence
The first thing to do is to pull the persistence related code out of the Nancy module. We use the following couple of tests to drive that. They use a Moq mock to specify the interface to the persistence code; that is the UrlStore interface:

    1 namespace ShortUrlTest

    2 {

    3   using Xunit;

    4   using Nancy.Testing;

    5   using Moq;

    6   using ShortUrl;

    8   public class UrlStorageTest

    9   {

   10     private Browser app;

   11     private Mock<UrlStore> fakeStorage;

   13     public UrlStorageTest()

   14     {

   15       ShortUrlModule artificiaReference;

   17       //Given

   18       fakeStorage = new Mock<UrlStore>();

   19       app = new Browser(

   20               new ConfigurableBootstrapper(

   21                 with => with.Dependency(fakeStorage.Object)));

   23     }

   25     [Fact]

   26     public void app_should_store_url_when_one_is_posted()

   27     {

   28       //When

   29       app.Post("/",

   30         with =>

   31         {

   32           with.FormValue("url", "http://www.longurlplease.com/");

   33           with.HttpRequest();

   34         });

   36       //Then

   37       fakeStorage

   38         .Verify(store =>

   39                 store.SaveUrl("http://www.longurlplease.com/",

   40                               It.IsAny<string>()));

   41     }

   43     [Fact]

   44     public void app_should_try_to_retrieve_url_when_getting_a_short_url()

   45     {

   46       //When

   47       app.Get("/shorturl",

   48         with => with.HttpRequest());

   50       //Then

   51       fakeStorage

   52         .Verify(store =>

   53                 store.GetUrlFor("shorturl"));

   54     }

   55   }

   56 }

A few interesting things go on in these tests.

Firstly, as stated above they specifify the interface UrlStore. They do so via the mock fakeStorage, and the calls to fakeStorage.Verify(...) which tells us that UrlStore should have two methods, SaveUrl and GetUrlFor.

Secondly we again use the Nancy.Testing.Browser type to call into the ShortUrl Nancy module. Remember that this goes though the whole Nancy pipeline, just like a real request from a browser. So we're genuinely testing the module from the outside. In the first test we do a HTTP POST, and in the second one we do a HTTP GET.

Thirdly in the constructor we're using another feature of Nancy.Testing; the ConfigurableBootstrapper. To understand this bit, a little detour is required. Nancy is very modular, everything in Nancy can be swapped for an alternative implementation via configuration. Furthermore Nancy apps uses IoC/DI from the get go. Out of the box Nancy uses TinyIOC, but that can (of course) be swapped with any other container - and NuGets exists for most (if not all) popular containers. The swapping out of things in Nancy apps is done through code, in a bootstrapper, which is a class in the app that implements INancyBootstrapper, and sets up the whole of Nancy and the app. To make this easy Nancy provides the DefaultNancyBootstrapper which can be used as the base class for app specific bootstrappers. Back to tests above. The ConfigurableBootstrapper, provides a simple way for tests to create specialized configurations through a fluent interface. The contructor in the code above registers the mock UrlStore as a dependincy, which means registering it in the TinyIOC container. In other words the parts of a the app that receives a UrlStore from the container will get the mock one when in the context of these tests.

But the UrlStore interface doesn't exists, so lets write it to make the tests compile:

    1 namespace ShortUrl

    2 {

    3   public interface UrlStore

    4   {

    5     void SaveUrl(string url, string shortenedUrl);

    6     string GetUrlFor(string shortenedUrl);

    7   }

    8 }

The tests don't run yet though, since our app does not use UrlStore at all. To make it do so, we change the application code to take a UrlStore in the module contructor, and use it for storage (particularly lines 7, 14 and 22):

    1 namespace ShortUrl

    2 {

    3   using Nancy;

    5   public class ShortUrlModule : NancyModule

    6   {

    7     public ShortUrlModule(UrlStore urlStore)

    8     {

    9       Get["/"] = _ => View["index.html"];

   10       Post["/"] = _ => ShortenUrl(urlStore);

   11       Get["/{shorturl}"] = param =>

   12       {

   13         string shortUrl = param.shorturl;

   14         return Response.AsRedirect(urlStore.GetUrlFor(shortUrl.ToString()));

   15       };

   16     }

   18     private Response ShortenUrl(UrlStore urlStore)

   19     {

   20       string longUrl = Request.Form.url;

   21       var shortUrl = ShortenUrl(longUrl);

   22       urlStore.SaveUrl(longUrl, shortUrl);

   24       return View["shortened_url", new { Request.Headers.Host, ShortUrl = shortUrl }];

   25     }

   27     private string ShortenUrl(string longUrl)

   28     {

   29       return "a" + longUrl.GetHashCode();

   30     }

   31   }

   32 }

And that makes the above tests run. But the end-to-end tests shown in part I don't run. The reason is they don't register a UrlStore with the container. They use the DefaultNancyBootstrapper, where no UrlStore is setup. To get past this we need to do a few things: Change the end-to-end tests to use an app specific bootstrapper, create an implementation of UrlStore that uses Mongo, and create an app specific bootstrapper. We'll start by driving out the Mongo implementation of UrlStore.

Shifting gears
To implement UrlStore against Mongo we need to shift TDD gears to using integration tests. The following tests, that drive the implementation of MongoUrlStore assume a Mongo server is running on localhost at port 27010:

    1 namespace ShortUrlTest

    2 {

    3   using System.Linq;

    4   using MongoDB.Bson;

    5   using MongoDB.Driver;

    6   using MongoDB.Driver.Builders;

    7   using ShortUrl.DataAccess;

    8   using Xunit;

   10   public class MongoUrlStoreTest

   11   {

   12     private string connectionString = "mongodb://localhost:27010/short_url_test";

   13     private MongoDatabase database;

   14     private MongoCollection<BsonDocument> urlCollection;

   16     public MongoUrlStoreTest()

   17     {

   18       //given

   19       database = MongoDatabase.Create(connectionString);

   20       urlCollection = database.GetCollection("urls");

   21         urlCollection.RemoveAll();

   22     }

   24     [Fact]

   25     public void should_store_urls_in_mongo()

   26     {

   27       //when

   28       var store = new MongoUrlStore(connectionString);

   29       store.SaveUrl("http://somelongurl.com/", "http://shorturl/abc");

   31       //then

   32       var urlFromDB = urlCollection

   33         .Find(Query.EQ("url", "http://somelongurl.com/"))

   34         .FirstOrDefault();

   36       Assert.NotNull(urlFromDB);

   37       Assert.Equal(urlFromDB["shortenedUrl"], "http://shorturl/abc");

   38     }

   40     [Fact]

   41     public void should_be_able_to_find_shortened_urls()

   42     {

   43       //given

   44       var store = new MongoUrlStore(connectionString);

   45       store.SaveUrl("http://somelongurl.com/", "http://shorturl/abc");

   47       //when

   48       var longUrl = store.GetUrlFor("http://shorturl/abc");

   50       //then

   51       Assert.Equal("http://somelongurl.com/", longUrl);

   52     }

   53   }

   54 }

These two test cases simply use the UrlStore interface, but also go directly to the Mongo instance to check that things are stored there. This is all quite straight forward, the one thing to notice though is that these test only assume that there is a Mongo server running, not that there is any particular database or collection present from the start. This is one of the ways Mongo is easy to work with, the databases and collections used in the code are just created for us behind the scenes. No friction.
To satisfy these tests we simply implement the UrlStore interface as follows:

    1 namespace ShortUrl.DataAccess

    2 {

    3   using System.Linq;

    4   using MongoDB.Bson;

    5   using MongoDB.Driver;

    6   using MongoDB.Driver.Builders;

    8   public class MongoUrlStore : UrlStore

    9   {

   10     private MongoDatabase database;

   11     private MongoCollection<BsonDocument> urls;

   13     public MongoUrlStore(string connectionString)

   14     {

   15       database = MongoDatabase.Create(connectionString);

   16       urls = database.GetCollection("urls");

   17     }

   19     public void SaveUrl(string url, string shortenedUrl)

   20     {

   21       urls.Insert(new {url, shortenedUrl});

   22     }

   24     public string GetUrlFor(string shortenedUrl)

   25     {

   26       var urlDocument =

   27         urls

   28           .Find(Query.EQ("shortenedUrl", shortenedUrl))

   29           .FirstOrDefault();

   31       return

   32         urlDocument == null ?

   33         null : urlDocument["url"].AsString;

   34     }

   35   }

   36 }

The thing I really want to point out here is line 21. We just tell Mongo to store an anonymous object and the driver does the rest for us (i.e. serializes it to json). No O/R mapping code!
Now we have an interface for persisting things, our module uses that interface, and we have an implemtation of it against Mongo. The only thing remaining is wiring things up.

Shifting gears back the end-to-end tests
As mentioned earlier the end-to-end tests from part I don't run right now, to make them run we first change their setup to use an app specific bootstrapper:

   14    public BaseUrlSpec()

   15    {

   16      ShortUrlModule artificiaReference;

   17      app = new Browser(new Bootstrapper());

   18    }

We've changed line 17 to use Bootstrapper instead of DefaultNancyBootstrapper. The type Bootstrapper does not exists yet, so lets create it, and have it register MongoUrlStore with the container:

    1 namespace ShortUrl

    2 {

    3   using Nancy;

    4   using DataAccess;

    6   public class Bootstrapper : DefaultNancyBootstrapper

    7   {

    8     protected override void ConfigureApplicationContainer(TinyIoC.TinyIoCContainer container)

    9     {

   10       base.ConfigureApplicationContainer(container);

   12       var mongoUrlStore = new MongoUrlStore("mongodb://localhost:27010/short_url");

   13       container.Register<UrlStore>(mongoUrlStore);

   14     }

   15   }

   16 }

We use the DefaultNancyBootstrapper as a starting point, and just use one its hooks to do a little bit of app specific setup, namely registering MongoUrlStore. Using other overrides we could configure anything in Nancy. I really like that a lot.

Well that's it. All tests run again.

Updated code is a available on GitHub.

Frictionless .NET Web App Development with Nancy Part II - Introducing a View Engine

2011-10-16T22:28:00.000+02:00

In the last post I introduced a litte sample web app coded up with the Nancy web framework. The code presented in that post left a few things open for later enhancement. This post takes a stab one of those things: The part where a string.Format is used to create a bit of html, which is then just returned directly to the client, namely the POST action in this code:

 3   using System.Collections.Generic;

 4   using Nancy;

 6   public class ShortUrlModule : NancyModule

 7   {

 8         private static readonly Dictionary&amp;lt;string, string&amp;gt; urlMap = new Dictionary&amp;lt;string, string&amp;gt;();

10         public ShortUrlModule()

11         {

12             Get["/"] = _ =&amp;gt; View["index.html"];

13             Post["/"] = _ =&amp;gt; ShortenUrl();

14         }

16         private string ShortenUrl()

17         {

18             string longUrl = Request.Form.url;

19             var shortUrl = ShortenUrl(longUrl);

20             urlMap[shortUrl] = longUrl;

22             return ShortenedUrlView(shortUrl);

23         }

25         private string ShortenUrl(string longUrl)

26         {

27             return "a" + longUrl.GetHashCode();

28         }

30         private string ShortenedUrlView(string shortUrl)

31         {

32             return string.Format("<a id=\"shorturl\" href=\"http://{0}/{1}\">;http://{0}/{1}</a>", Request.Headers.Host, shortUrl);

33         }

34     }

Specifically the last method, 'ShortenedUrlView' is bad code: It's brittle, it doesn't produce valid HTML, and it's open for script injection. Therefore I want to separate that bit of view code from the module code: I want a view engine. Luckily Nancy supports a number of standard view engines(Razor, Spark, DotLiquid, NDjango) each of which are only a NuGet package away, but it also comes with its own appropriately named Super Simple View Engine, SSVE. For this sample SSVE will do, so let's just stick with that.

We add a file called shortened_url.sshtml to the Views folder and put this into it:

<html>
<body>
<a id="shorturl" href="http://@Model.Host/@Model.ShortUrl">
http://@Model.Host/@Model.ShortUrl
</a>
</body>
</html>

As with Razor views the @ indicates code snippets. In the above we insert 'Host' and 'ShortUrl' properties from the view model in the view.

To use this we also need to modify the Nancy module code a bit. We need to return a View[] instead of simply a string:

   21         private Response ShortenUrl()

   22         {

   23             string longUrl = Request.Form.url;

   24             var shortUrl = ShortenUrl(longUrl);

   25             urlMap[shortUrl] = longUrl;

   27       return View["shortened_url",

   28         new { Host = Request.Headers.Host, ShortUrl = shortUrl }];

   29         }

   31         private string ShortenUrl(string longUrl)

   32         {

   33             return "a" + longUrl.GetHashCode();

   34         }

We saw use of View[] last time, this time around we provide a model object along with the view name. This object is passed to the view code as the @Model.

That's it. Introduced a view engine. No friction.

The code for this sample is still available on GitHub. Now with the updates described here.

Frictionless .NET Web App Development with Nancy

2011-10-10T22:34:00.000+02:00

This post is about a low ceremony approach to web apps in .NET. It's about just writting the app, without the framework getting in the way. It's about the same sort of feeling that Mogens Heller Grabe talks about with his notion of frictionless persistence with MongoDB. Only here it's about the web part.

I'll take you through a short and simple URL shortener sample app done with the Nancy web framework. A couple of more posts will probably follow on the subjects of view engines, persistence and hosting for this app. Also with an eye on low ceromony and frictionsless development.

What is Nancy?
Nancy is a lightweight open source web framework in .NET. It has a declared goal of being the developers super-duper-happy-path. Nancy is lightweight in the sense that the number of concepts and the amount syntax you have to grok is minimal. That's why I like it, and that's why it provides the frictionless experience I'm after here.

First things first: The first red-green cycle
One of the first very nice things to notice about Nancy is that it supports TDD really well (much more so than ASP.NET MVC), so lets start looking at the sample by looking at the first test:

    9 public class BaseUrlSpec

   10 {

   11   [Fact]

   12   public void should_respond_ok()

   13   {

   14     var app = new Browser(new DefaultNancyBootstrapper());

   15     var response  = app.Get("/", with => with.HttpRequest());

   16     var statusCode = response.StatusCode;

   17     Assert.Equal(HttpStatusCode.OK, statusCode);

   18   }

   19 }

This is just an ice breaker test to get us going: It just tests that our app responds with an http 200 OK status code. There are nevertheless a couple of things to notice:

Nancy.Testing provides us with the Browser class, which gives our tests an easy way to interact with the app as if they were a browser: The browser object allows for doing GET, PUT, POST and DELETE, PATCH and OPTIONS against the app, including setting up the body, the headers and the protocol. In the case of the above we're doing a GET over http to the relative URL "/", no body, no special headers.
Nancy.Testing also provides a BrowserResponse type that allows for testing all sorts of things on the response from the app. The variable 'response' in the above has this type. Here we just check the status code, but in later examples we'll do a lot more.

There, that's the red part.

To make this run we only have to write this little snippet of Nancy based code:

    4   using Nancy;

    6   public class ShortUrlModule : NancyModule

    7   {

    8     public ShortUrlModule()

    9     {

   10       Get["/"] =_ => HttpStatusCode.OK;

   11     }

   12   }

Firstly this little piece of code shows the central concept of Nancy: It provides a DSL for responding to http requests. It does so by letting you specify what code should run on GET, PUT, POST, DELETE, PATCH and OPTIONS requests for different URIs. In the above we only specify one such action for one URI: GET for '/'. Secondly it shows another defining trait of Nancy: The framework really tries to make things easy for you, in this case illustrated by the fact we just return a 200 OK status code, but Nancy accepts that and turns it into a full response for us.

GETting the form
So returning a 200 OK does not make for much of an app. What we want here is a very simple URL shortener, so lets turn the front page of the app into a form with a field for the URL the user wants shortened and a submit button. Again we start with a test:

   28     [Fact]

   29     public void should_contain_a_form_with_an_input_field_for_a_url_and_a_button()

   30     {

   31       //when

   32       var baseUrlGetResponse = app.Get("/", with => with.HttpRequest());

   34       //then

   35       baseUrlGetResponse.Body["form"]

   36         .ShouldExist();

   38       baseUrlGetResponse.Body["input#url"]

   39         .ShouldExistOnce();

   41       baseUrlGetResponse.Body["label"]

   42         .ShouldExistOnce().And

   43         .ShouldContain("Url: ");

   45       baseUrlGetResponse.Body["input#submit"]

   46         .ShouldExistOnce();

   47     }

Here we see some more of Nancys test emphasis: The BrowseResponse type mentioned above provides a Body property that lets our tests search through the body of the response using CSS selectors and make assertions on the results using a set of fluent 'Should' style extensions. For instance the above asserts that there is exactly one input tag with the id 'url' and that there is one label tag which furthermore contains the text 'Url: '. This, I must sat, is just awesome, and is a very good level to test at: Just below the pixels of the UI, and just above the real http stack of the real web server.

To make this run we need only do slightly more than in the previous cycle: We alter the application code to this:

 4   using Nancy;

 6   public class ShortUrlModule : NancyModule

 7   {

 8         public ShortUrlModule()

 9         {

10           Get["/"] = _ => View["index.html"];

11         }

12   }

and add the following index.html file to a Views folder:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body>
<form method="post">
<label>Url: </label>
<input type="text" name="url" id="url"/>
<input type="submit" value="shorten" id="submit"/>
</form>
</body>
</html>

Now we see Nancy trying to make things easy again: Just indicate in the application code that you want to return a view by saying View["index.html"], and Nancy looks in your views folders, finds the view and off we go.

POSTing the form
Next step is reacting to a POST of the form we just made, by shortening the URL. Let's set up a test for that:

 49     [Fact]

 50     public void should_return_shortened_url_when_posting_url()

 51     {

 52       //when

 53       var baseUrlPostResponse = app.Post("/",

 54         with =>

 55         {

 56           with.FormValue("url", "http://http://www.longurlplease.com/");

 57           with.HttpRequest();

 58         });

 60       baseUrlPostResponse.Body["a#shorturl"]

 61         .ShouldExist().And

 62         .ShouldContain("http://");

 63     }

Here we see how the app object is used for sending a POST to the app, and along with it the appropriate form values; in this case just the url. This starts to show the flexibility and ease of use of the Browser type.

Considering how we've handled the GET request until now, handling the POST is as straightforward:

 3   using System.Collections.Generic;

 4   using Nancy;

 6   public class ShortUrlModule : NancyModule

 7   {

 8         private static readonly Dictionary<string, string> urlMap = new Dictionary<string, string>();

10         public ShortUrlModule()

11         {

12             Get["/"] = _ => View["index.html"];

13             Post["/"] = _ => ShortenUrl();

14         }

16         private string ShortenUrl()

17         {

18             string longUrl = Request.Form.url;

19             var shortUrl = ShortenUrl(longUrl);

20             urlMap[shortUrl] = longUrl;

22             return ShortenedUrlView(shortUrl);

23         }

25         private string ShortenUrl(string longUrl)

26         {

27             return "a" + longUrl.GetHashCode();

28         }

30         private string ShortenedUrlView(string shortUrl)

31         {

32             return string.Format("<a id=\"shorturl\" href=\"http://{0}/{1}\">http://{0}/{1}</a>", Request.Headers.Host, shortUrl);

33         }

34     }

This is all pretty straight forward. The Nancy parts of this are:

The use of POST...which does just what you expect.
The return of a string in the last method. That bubles all the way up, and becomes the repsonse back to Nancy. Again Nancy is nice to us, sets the content type to text/html and the status code to 200 OK. This is not the nicest code on my part, so I might just return to refactor it in a future post.

The above of course is not very clever about the shortening, and does not exactly persist the short URLs in a good permanent place. I'll return to the persistence in a furture post.

Redirect
Only one part is missing for a simplistic but functioning URL shortener: The app must redirect the shortened URLs to the original longer one.
Again lets start with the test:

 65     [Fact]

 66     public void should_redirect_to_original_url_when_getting_short_url()

 67     {

 68       //when

 69       var baseUrlPostResponse = app.Post("/",

 70         with =>

 71         {

 72           with.FormValue("url", "http://www.longurlplease.com/");

 73           with.HttpRequest();

 74         }).GetBodyAsXml();

 76       var shortUrl = baseUrlPostResponse

 77         .Element("a")

 78         .Attribute("href").Value

 79         .Split('/')

 80         .Last();

 82       //then

 83       app.Get("/" + shortUrl, with => with.HttpRequest())

 84         .ShouldHaveRedirectedTo("http://www.longurlplease.com/");

 85     }

We do the POST again, find the short URL with a bit of LINQ-to-xml and then do a GET to that. And then just assert that the redirect happened. Pretty straight forward except maybe for the Linq-to-xml part.

To make the last test run we add this to our application code:

 14  Get["/{shorturl}"] = param =>

 15  {

 16     string shortUrl = param.shorturl;

 17     return Response.AsRedirect(urlMap[shortUrl.ToString()]);

 18  };

which is an action for a whole set of URIs, namely the URIs matching the URI template "/{shorturl}". In the action we access the 'shorturl' part of the URI through the param.shorturl; all parts of the templatized URI will be availbe like that through the dynamic param. Nice.

That's it. We have a simplistic URL shortener. No friction.

The source is availble on github, and more Nancy information is avaible on the Nancy web site.

Tip for making AutoFixture and xUnit.net play nice

2011-09-06T22:24:00.000+02:00

Just a quick tip, for making AutoFixture 2.1 play nice with newer xUnit.net versions:

I installed Autofixture via NuGet, which gave me AutoFixture 2.1 and xUnit 1.7, when running my tests they threw this:

System.IO.FileNotFoundException:
Could not load file or assembly
'Ploeh.AutoFixture, Version=2.1.0.1, Culture=neutral,
PublicKeyToken=b24654c590009d4f'
or one of its dependencies.
The system cannot find the file specified.

The reason is that the test runner thinks that AutoFixture needs and older version of xUnit (although it doesn't really).
The solution is to put this in the app.config for the test projects:

    1   <runtime>

    2     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

    3       <dependentAssembly>

    4         <assemblyIdentity name="xunit.extensions"

    5                           publicKeyToken="8d05b1bb7a6fdb6c"

    6                           culture="neutral"/>

    7         <bindingRedirect oldVersion="1.6.1.1521"

    8                          newVersion="1.7.0.1540"/>

    9       </dependentAssembly>

   10     </assemblyBinding>

   11   </runtime>

You'll probably have to fix up the newVersion to the exact version you have.

That's it for now.

Upcoming Events

2011-09-05T10:39:00.002+02:00

I have couple of events coming up that I thought I'd share here: The Agile Architecture Open Space Conference and an ANUG code camp on enhancing legacy test suites.

Agile Architecture Open Space Conference
On the 29th and 30th of September a couple of colleagues and I are running a small conference under the headline of sustainable architecture in an agile world. It's an open space conference, so there's next to no official program. But there is plenty of room for in-depth discussions and networking. With the line up of attendees so far I think it'll be awesome. There are still a few spaces left, so check it out at http://aaosconf.eventbrite.com/.

Enhancing Legacy Test Suites
On the 19th of November I'll be running a code camp on the subject of enhancing legacy test suites. It'll be a longer, more in-depth and more hands-on version of the workshop on the same subject I did at SC2011. The premise of the code camp is that we see more and more code bases with some automated tests around them, but these tests are often lacking in quality. The tests are sometimes just there to cover somebody's ass, sometimes they are very tightly coupled to the implementation, sometimes they are flaky, and they almost always cover only a fraction of the production code.
At the code camp we'll dive into techniques to improve this situation, and move towards a situation where the test suite is an asset. Where the tests are not a burden to maintain, and where they provide the confidence they should.
I'll start the day by introducing a few techniques, and an example code base with some tests associated. The bulk of the day will be spent applying the techniques to the example code base through a number of iterations with tasks set be me for each one. Should be a lot of hacking fun

Developer Survey Results - Part 4

2011-08-29T23:25:00.000+02:00

This is the forth and last post in my series summaries of the develop practices survey I ran (the other posts are here, here and here).

This one is about practices to ensure code quality. But tool driven things. I'm less interested in the use LINT-style tools, than in the use reviews, pair programming and refactoring. so the last ones were the ones I asked about.

Asking "do you pair programming" survey says:

Yes, all the time			2%
Yes, often			6%
Yes, from time to time			19%
No, almost never			47%
No, never			18%

In other words, next to no respondents practice pairing often, and two thirds almost never or never practice it. , I honestly almost never pair myself. Can't decide if this is good or bad.
Next question was if respondents use code reviews. The responses were:

Yes, all code is reviewed			6%
Yes, most code is reviewed			16%
Yes, some code is reviewed			27%
No, almost no code is reviewed			34%
No, never			8%

Again usage is pretty low. Now, this I do think is a waste. In my experience reviews really do work, when they are kept at the right balance between the totally informal "just discussing stuff" and the totally formal "you have to sign this before you leave".
Of the 92% that do use code reviews on at least at bit of code now and then, the types of reviews used were:

Formal reviews with formal approvals			4%
Formal reviews without formal approvals			17%
Code walk throughs			48%
Active design reviews			7%
"Hey, come take a look at this code on my screen"			72%

The weight here is one the more informal review types. Not surprising I guess. They are easy and cheap. And they can return a lot of value.Lastly I asked about a personal favorite - something I think is absolutely necessary in order keep code maintainable: "Do you use refactoring?" The responses were:

Yes, I always try to leave the code cleaner than I found it			26%
Yes, from time to time			44%
Yes, as separate tasks			10%
No			11%
Other			10%

Which is a fairly good note to end on :-)

Developer Survey Results - Part 3

2011-07-31T22:04:00.009+02:00

This is the third part of my walk through of the results of a survey I recently did (part 1, part 2). This time I focus on practices around continuous integration.

The survey shows that 58% of respondents use CI, which is fewer than I expected.

Those who use CI have their CI servers do different things. The answers show respondents use their servers to:

Build			94%
Run unit tests			86%
Run integration tests			75%
Run system tests			22%
Run UI tests			14%
Run acceptance tests			14%
Create release or deployment package			58%
Create tag/branch in source control on success			19%
Deploy to non-production environment (like test or staging)			22%
Deploy to production			11%
Other			8%

So - not surprisingly - people build their code on the CI server. Then they seem to run the tests they've written - the numbers for running different kinds of tests align nicely with the numbers for writing different kinds of tests (see part 1). Furthermore over half create releases of deployment packages. That's pretty high, I think - even if it's only just over half of the half of the respondents that use CI at all; i.e. about a quarter of all respondents. Only very few take the next step and actually deploy to production. This is as expected; continuous deployment is still pretty new.

Next question how often CI runs and it shows that by far most people have it running on every commit.

Turning to how often things brake the distribution is as follows:

Most of the time			11%
Several times a day			3%
Once a day			33%
Once a week			42%
Once a month			6%
Never			3%
Other			3%

So its seems something is broken sort of often. Is that a problem? -Not in my opinion. It just shows that the CI server finds stuff. What could be a problem is if this stuff isn't fixed. Asking about how long from something brakes to work to fix it is started the answer were:

Within 15 minutes			22%
Within an hour			47%
Within half a day			14%
Within a day			11%
Within a week			3%
Within a month			0%
Never			3%
Other			0%

which I thinks shows that the issues found by CI are taken seriously.

All in all, it's a mixed impression on this one: Too few do any CI, but those who do have it build, run the tests they have, and create releases. And they react quickly to issues.

Developer Survey Results - Part 2

2011-07-06T21:10:00.000+02:00

This second part of my walk through of the result of a survey I did recently focuses on practices around source control.

Again this section of the survey started by asking if respondents use source control at all. Luckily most did, 95% (although, what do those last five percent do? -They also answered that they code more than 10% of their time at work).

So looking at the distribution among source control systems, the results were:

Sourcesafe		6%
TFS		11%
CVS		2%
SVN		72%
Git		22%
Mercurial		6%
ClearCase		17%
Other		11%

This is not to be seen as an indication of the popularity of each of these vcs's in general, just as background on what the respondents to this survey use. And, as can be seen, this is an SVN crowd. That may very well have an effect on the rest of the answers in this section.

How often do respondents commit, then? -I think this an important indicator of how developers work. Do they take small focused steps, or big leaps of faith? Well, here are the results:

All the time		3%
Several times an hour		6%
About once an hour or every other hour		18%
About twice a day		34%
About once a day		23%
About once a week		3%
About once a month		0%

So the weight here is around the twice a day answer. Some a bit more often than that, and some a bit less often that than. That's OK. I've seen shops where the norm was committing once a month. Awful. But these result do - on the other hand - leave room for improvement. I don't think commiting once an hour is unreasonable for the vast majority of development tasks. And more often if you're using a distributed version control system.

Last question in this section was about how the VCS is used in terms of branching and the likes. Results are:

Feature branches		39%
Experimentation branches		35%
Release branches		59%
Tags		57%
None of the above		15%
Other		0%

Don't know what to say about this. People use some amount branching generally it seems, but I suspect some of these would differ if most respondents had been Git users instead of SVN users. I don't know.

Next section of the survey was about continuous integration. I'll cover that in my next post.

Developer Survey Results - Part 1

2011-07-01T22:40:00.001+02:00

I ran a survey recently asking about a variety of practices on the developer level. The survey is now closed and the results are in.
The areas covered in the survey were test automation, source control, continuous integration, and code quality assurance. Nothing too fancy, but a collection of practices that I consider important, and which are all quite well known. I was curious to see how wide spread these practices are.

In this post I'll cover the results of the first part.I got 62 responses to the survey. Not enough for statistical significance. And there's probably also some bias in the group, since they come mainly from my network. So don't take the results for more than they are.

Test Automation Practices

So 71% of respondents use automated tests. That's pretty high. And then again it's sort of low. The benefits of test automation are so widely accepted, that did actually expect this number to be even higher.The next few questions where only asked of the respondents that use automated tests.Here's how many respondents use each type of test automation:

Unit tests	95%
Integration tests	80%
Systems tests	20%
UI tests	14%
Acceptance tests	16%
Performance tests	20%
Load tests	11%

So unit tests and integration tests are wide used, while the rest are only sporadically used. No big surprise, I'd say.

Next I asked how much of the code is covered. This is an important question; there's a lot of difference in what tests gives you between having low coverage percentages, having high percentage and having 100%. So how much do respondents cover?

0-25%	14%
25-50%	34%
50-75%	36%
75-100%	20%
I can't estimate that	2%

Not too high.So who writes those tests?

I do	98%
The testers do	9%
The business people do	0%

...responds writes their own tests. That's good.So when are the tests written?

Before the production code (test first)	3%
Along side the production code (sometimes before, sometimes right after)	47%
Shortly after the production (after production code, but in the same workflow)	19%
After the production code for a complete feature is finished	2%
During a separate test phase	0%

...so mainly alongisde or shortly after. But not before. This probably explains why the coverage percentages seem to be a bit low.

OK, I'll the rest of the interpretation to you.

Next post I'll go through the result for the source control questions.

Take-Away Points From my Software Craftmanship 2011 Session

2011-05-27T20:07:00.000+02:00

At the Software Craftsmanship 2011 conference yesterday I had the pleasure of running a workshop on how to deal with "legacy" test suites. A part from having a lot fun I also learned a lot from the discussions during the workshop.

The premise of the workshop was a problem that I think is becoming more and more common: Even though more and more code bases have test suites around them, the quality of those tests are low. This lack of quality can stem from a number of things. First of all most automated tests, in my experience, still aren't written in a TDD workflow, they are written some time after the production code. Sometimes right after, sometimes days or weeks later. Secondly automated testing efforts sometimes seem to lack a clear purpose. Lastly test suites are often (as in very often) abandoned as soon the project comes under any sort of pressure - from deadlines, budgets, changing requirements or whatever else. These things lead to test suites that are treated as second or third class code; code that is not seen as important. That leads to a range of problems, such as tests with bland names - like test001 - tests that assert nothing or next to nothing, tests that just mimic the structure of the implementation without showing or exercising the behaviour from a domain/specification perspective and to low coverage of both code and features.

To get concrete we took a hard look at the tests for the NerdDinner sample application. In there we found most of the problems listed above, which begs the question given that we where taking over maintainance and future development of NerdDinner how would we proceed with regard to the tests. Clearly the existing tests are not at a quality level that would allow us to have confidence in the changes to NerdDinner we make just based on the tests running. On the other hand they do cover about a third of the code, and most of them do assert stuff. So if one of them was to break that likely indicates a problem.

The discussion during the workshop seemed to divide people into two camps: One that said, that these test are not worth carrying forward because they will require maintainance while not providing any real value as regressions guards or as specifications. The other camp said, keep them and incrementally improve or delete them, keeping in mind that we dont know how valid the individual tests are.

To sum up the main points I got from the throw the test away camp were:

Since coverage is way too low, we're better off with a small number of broad acceptance tests. We can write those in the initial iteration, where we need to familiarize ourselves with the code base anyway.
Tests that don't assert much just gives us false confidence, so they are a liability that we don't want to keep them around.
Tests that don't work as specifications are mainly a confusion to us, because we don't have access to the people that wrote, and consequently can't find out what the purpose of those tests was.
It's simply quicker to write a bunch of exploratory tests, than it is to try to understand and maintain the existing ones.

And the main points I got from the keep the tests camp were:

Even though there are problems with the tests, each of them were written with some sort of a goal in mind. As such we suspect that they can point out something we haven't realized yet.
The tests are just another part of the code base, and as such it's natural that we will have to refactor - and improve - them over time.
We can put the legacy tests in some kind of a quarantine, where we keep running them but don't necessarily trust them, and when one breaks we take look at it and then decide to either delete the test or fix it and move it from the quarantined suite to our normal test suite.
The Boy Scout Rule applies to tests as well. Use that as the discipline to incrementally improve the tests.

In general I'm in the keep the tests camp, but I guess it really comes down to making an informed decision on a case-by-case basis. Which camp are you in? Or which points do think we missed?

Building DCI Context with ASP.NET MVC

2011-05-04T07:59:00.001+02:00

In this post I'll address one of the questions that I tend to get when talking about DCI: How is the DCI context built at runtime?

To that end lets expand a bit on the DCI with ASP.NET MVC sample that I showed in an earlier post. The focus of that post was how to fit ASP.NET MVC and DCI together in a nice cohesive architecture. In this post I will zoom in on how the controller can build up the DCI context object in a conversation with the user.

The example I'm using is still that of a very simplified online bank, where the user can trasfer money between accounts. The core DCI parts of this example is explained in this post, and the connection with ASP.NET MVC in this post. Whereas the sample in the last post simply asked the user to input all the information about the transfer in one screen, this version asks for the information one thing at a time in a wizard like fashion. Whether this is good UX, is besides the point of this post. I just want to use an example where the context is build in a series of interactions with the user.

Interaction Between User and Code
First off the user is asked to choose a source account on this simple (ugly) page:

Serving up this page is done by this rather straight forward action method:

    1  public ActionResult SelectSource()

    2  {

    3      Session["Context"] = new TransferMoneyContext();

    4      return View(new SelectAccountVm

    5                  {

    6                      SelectedAccountId = string.Empty,

    7                      Accounts = accountRepo.Accounts

    8                  });

    9  }

Worth noticing though, is that a MoneyTransferContext object is created and stored in the session.
When the user hits the Next button this action is hit:

   55 [HttpPost]

   56 public ActionResult SelectSource(SelectAccountVm model)

   57 {

   58     var ctx = Session["Context"] as TransferMoneyContext;

   59     ctx.Source =

   60       accountRepo.GetById(int.Parse(model.SelectedAccountId)) as TransferMoneySource;

   61     return View("SelectDestination",

62 new SelectAccountVm

   63                 {

   64                     SelectedAccountId = string.Empty,

   65                     Accounts = accountRepo.Accounts

   66                 });

   67 }

This code updates the context with the chosen source account, and serves the next view in the interaction, where the user is asked for a destination account:

When the user hits this Next button this action is hit:

   69 [HttpPost]

   70 public ActionResult SelectDestination(SelectAccountVm model)

   71 {

   72     var ctx = Session["Context"] as TransferMoneyContext;

   73     ctx.Sink =

   74       accountRepo.GetById(int.Parse(model.SelectedAccountId)) as TransferMoneySink;

   75     return View("SelectAmount", new SelectAmountVm());

   76 }

which does almost the same as the previous action, except it puts the chosen account in the Sink property on the context, and then shows this page:

The post from this page does a bit more work. First it updates the context with the amount given by the user. At this point the MoneyTransferContext is complete and ready to be exectued. Finally a result page is shown:

   78 [HttpPost]

   79 public ActionResult SelectAmount(SelectAmountVm model)

   80 {

   81     var ctx = Session["Context"] as TransferMoneyContext;

   82     ctx.Amount = model.SelectedAmount;

   84     ctx.Execute();

   86     return ResultPage(ctx);

   87 }

and the result page is:

Summing Up

To sum up: To build up a DCI context in ASP.NET MVC simply store a context object in the session context when a use case is started and execute it when it makes sense from a functionality perspective. This way the controller code is kept very simple, concentrating only on building up the context through interaction with the user, and the details of the use case execution is - from the perspective of the cotroller - hidden behind the context. Furthermore because of the way the controller builds the context the context object only knowns the domain objects through the roles they have been assigned by the controller - or in fact the user - allowing for the full strenght of DCI to play out there.

You can find the complete code from this post on GitHub.

Impressions of NDepend

2011-04-06T16:13:00.000+02:00

I've been giving NDepend a go lately, in part because I've had my eye on it for a while, and in part because Patrick Smacchia offered me free trial of NDpedend Pro recently

I decided to try out NDpedend in a few different scenarios, that relate to different ways I might use it at work, so I spent a few hours with NDepend on three different code bases

A small code base - ~3KLOC - that I know quite well because I wrote 80% of it.
A medium sized code base - ~70KLOC - that I also know well because I worked on the team that wrote. But I only wrote a small portion of it myself.
A small code base - ~5KLOC - that I don't know at all. -I've only had a 10 minute intro to the architecture.

These, IMHO, span a number of scenarios where I might use NDepend: From scenarios where I know the code well, but want NDepend to help keeping myself and my team in check, to scenarios where I am reviewing or taking over an unknown code base, and want NDepend to help me get an overview and to help me drill into problematic areas.

Ok, but lets back up a bit: What is NDepend? -NDepend is a static analysis tool for .NET code that provides metrics like cyclomatic complexity, average and max methods per class, average and max statements per method, assembly dependencies, namespace dependencies and so on. Check the NDepend site for the full feature list.
And what does the pro version offer? -The pro version is an interactive version of the free NDepend. The free version will spit out a report with all the metrics in them, for you to look at, but the pro version integrates with Visual Studio to give you the possiblity to drill into the data, and to modify the metics using the so-called Code Query Language - CQL.

My observations in general from running NDepend on the three code bases listed above:

NDepend is pretty fast, at least when the code bases are not too big. This is less important if you intend only to run NDepend on your CI server as a late stage step, but if you want to take an interactive approach it's crucial.
The interactive drill down capabilities of the pro version are enticing...is that good or bad?...for me, on the one hand, it meant that I actually discovered more about the code bases than I think I otherwise would have, on the other hand, I also spent more time than I planned to.
The default NDepend analysis is expressed in CQL queries that can be modified in Visual Studio, which I used to tighten some of the metrics. Doing that was dead easy, and is a real benefit because it allows you to go with your own standards.
The default warning levels for the different metrics are, in my opinion, not tight enough. I especially want fewer statements per method and lower cyclomatic complexity. So that's sometihng I be tweaking in future uses of NDepend.

My observations relating specifically to the three code base above are:

NDepend did not tell me anything I did not know about this code base. -But it's also a degenerate case becasue the code base is so small and because I wrote most of it myself, so I have all it in my head anyway.
This case is a lot more interesting: The code base is of a size where it is hard to hold it all in your head, and it was written by a team, so no one person has actually looked deeply at all the code. For this code base NDepend gave me some interesting insights:
- NDepend was able to produce a very sensible list of methods and classes that need refactoring. About half of them I was aware already, but the other half I wasn't.
- NDepend was also able to pin point to major areas where the problematic code was concentrated. I sort of knew those were pain points, but NDepend made it a lot clearer. That's a big win.
- NDepend quickly produced a complete dependency graph, with a half hour of moving boxes around, deleting irrelavant boxes and so on I had a useful diagram of the dependencies in the project. That was actually something we had wanted for a while, but hadn't gotten around to, so that was a nice by-product.
The third code base was another small one, but one I didn't know. In this case NDepend gave me:
- A quick overview of the internal and external dependencies. Again in a fairly clear and readable diagram that the teams tech lead was able to confirm quickly
- Pinpointed the two methods that very overly complex (2 aren't many BTW - that team did a good job, so far)
- A single instance of a cyclic namespace dependency - that the teams tech lead wasn't aware of

To sum it's been very easy to get up and running with NDepend, and the tools has provided valuable insights in two of three cases. Considering that the first case was small and written mostly by me, it's not big deal that NDepend didn't tell me anything new in that case (in fact it would have been sort of a big deal if it had - I should know those things already). I recommend giving NDepend a go, I know will be using it routinely in the future for code bases I work on and for code bases I review.

Why Commit Comments Matter

2011-03-14T21:27:00.000+01:00

Lets look at something pretty basic: Commit comments. Why are they important? -Good commit comments should summarize the context and intent of the commit. Writing good commit comments gives you a better version history and gives you better individual commits. Lets look at each of these claims in turn.

Better Version History
Good commit comments makes the version history better in a number of ways:

Having commit comments that summarize intent turns the commit history of the previous day into a quick way for team members to check what happened in the code base yesterday - and they can readily drill down into the code diffs if they want.
Having commit comments that summarizes the context of the commit - e.g. by including a bug report number or a user story id - is a very simple and flexible way to introduce traceability from code to requirements.
Having commit comments that summarize the context and the intent is an excellent tool for understanding code later on: When something seems to work, but also seems a bit odd, it is great to be able do an svn blame or git blame and get an idea of the context and intent behind that code.

Better Individual Commits
Writing good commit comments requires just a little bit more thought than writing no comment or writing a non-comment like "checking in code" or "bugfixes" or "I'm going home now". That little bit of extra thought is quite often just enough to make you realize if your commit could break that other part over there, or that you haven't run all the relevant tests, or that it just isn't one cohesive whole and should be split into two or three individual commits. That last point can also lead you to committing more often, and as a result synching and integrating with the rest of the team more often. Good cycle.

But I'm In a Hurry
Yeah, well we all are. So don't waste teammates time by breaking the build or having them read through the version history diff by diff just so you save a commit comment. Besides writing good commit comments really doesn't take long. Seriously we're talking 10 seconds. Just pick a format and stick to it. I like

That's quick to write, right?

Testable C# or C# TUFs and TUCs

2011-02-25T21:51:00.001+01:00

Re-reading Michael Feathers nice article on "Testable Java" I decided to see how the same thing looks in C#. Now, Java and C# aren't too far a part, so the difference isn't huge.

The "Testable Java" article gives a simple rule for how we can write code that is friendly to unit tests. -As the article points out the rule is superflous if we follow TDD stricly. But - being human - we don't always do that. Sometimes we write only integration tests or even acceptance tests here and now, and postposne unit tests. Sometimes we skip the automated tests altogether. In these cases it's an advantage to have code that is at least friendly to unit tests. If so, it's afordable to add the unit tests later.

Feathers' rule is:

"Never hide a TUF within a TUC"

and Feathers goes on to define TUF as a "Test Unfriendly Feature" and TUC as a "Test Unfriendly Construct". Now TUFs are things that we want to mock out in many unit tests, but TUCs are language constructs that are hard to substitute for testing.

TUFs

Examles, from the article, of TUFs:

Database access
File system access
Network access
Access to side effecting APIs
Long running computations
Inscrutable computations
Static variable usage

The first three are basically I/O, and in general I/O is test unfriendly because it is slow, and usually assumes things about the outside world - like "the webservice is reachable" or "the robot arm is connected through the serial port".
The next - side effects - is about avoiding tests that changes something and annoys somebody.
Long running computations are a nuisance, and will make you skip test runs.
Inscrutable computations, are things that are just plain hard to understand - maybe due the "clever" code-smell or to essential complexity.
These TUFs are all TUFs in .NET as well.

TUCs

The article lists a number of Java TUCs. This is my ported list of C# TUCs:

Sealed classes
Static methods
Private methods
Static initializers
Constructors
Static constructors
New expressions

and these are few more C# TUCs IMHO:

Non-virtual methods
Internal methods
Internal classes

The point is to remember - even when you skip the TDD strictness - that testability is an important part of maintainability. So if maintainability is quality attribute you want, then keep an eye on the testability. If not, those TUFs inside of TUCs will come back and bite you.

Oh, and the other point: Go read Michael Feathers' article. It's well worth it.

Random Thoughts on Tiobe Index January 2011

2011-02-03T00:09:00.000+01:00

The Tiobe index is an index of the popularity of programming languages (formally defined here).
According to the Tiobe web site "the index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system."

Some Data to Notice From the Index

As someone who has worked mainly in .NET through the last several years, my interest in the index focuses on .NET languages (and on my favorite language for recreational coding for some time now: Scala). The rankings of .NET languages in the January 2011 index are:

F# ranked between 50 and 100 (the index put these 50 in one big pile because differences the in scores are minuscule)
VB.NET at no. 49
PowerShell at no. 28
C# at no. 6

For perspective here are some selected other languages:

BETA ranked between 50 and 100
AWK at no. 31
T-SQL at no. 17
Ruby at no. 10
VB at no. 7
Python at no. 5

And also worth noticing is that Java, C and C++ take the top 3 spots, and have for a decade.

What I Get From That Data

Now what does this mean for a .NET developer?

C# is hugely popular, but still much, much less popular than Java. Looking at the long term trend C# is steadlily gaining ground. So having and maintaining C# skills is a really good idea in terms of making a living.
VB.NET is so unpopular it's almost off the charts...in a bad way. But (!) considering how the Tiobe index is done I don't think it distinguishes VB and VB.NET properly. So IMHO it's more fair to add the VB and VB.NET scores which would place VB.NET at 5th place - where VB is now. If this is true having VB.NET skills is a really good idea too, but the long term VB.NET trend is downwards, especially over the last couple of years. So maybe it's time to translate those VB.NET chops to C# chops?
F# doesn't seem to be going anywhere. So don't learn F# for job security. Learn it to open your mind. But then again, if you want to open up your mind, and you're a .NET dev, why not look outside .NET and do Scala or Clojure or Erlang or something completly left field?
PowerShell seems to be becoming important. Maybe it's time to really learn it.

What does it mean for the .NET community?

Assuming the VB and VB.NET points needs to be added C# and VB.NET combined would weigh in at a 3rd place, meaning that .NET is doing very, very well in terms of popularity.
Both Ruby and Python are doing very well. So if the Iron* languages are dropped an opportunity for engaging two very large communities is lost. That would be really sad!

Those were my 2 cents. Go check the index out, and make up your own mind. And let me know what you think :-)

Oh, and Scala is at place 50, just within the list proper. Still rooting for it :-)

Doing DCI with ASP.NET MVC

2011-01-13T22:01:00.001+01:00

The DCI - Data, Context, Interaction - paradigm (intro article, an earlier post) brings the roles domain objects play at runtime to center stage. DCI also fits right into the gaps of MVC. What? Which gaps?

MVC Gaps
Back in the day, when MVC was originally described by Trygve Reenskaug as an architecture approach it was all about the users mental model, giving the user the sense of just working directly with the domain objects. Now dont confuse this with the dreaded CRUDy forms-over-data battleship grey enterprise app. Those apps force the user to manipulate the data directly; respecting, fighting and being forced into submission by the techniocal details of databases. MVC on the other hands puts that the model is the users mental model - the programmer, then has to deal with hiding the technicalities of persistence and such. As illustrated below the users works as if manipulating the domain objects directly. The view simply reflects the model state, the controller reacts to user actions, and translates them to model updates, and that's it.

Direct manipulation metphor as illustrated by Trygve Reenskaug

This is fantastic for fairly simple apps. But as soon we introduce business rules with a certain amount of complexity, the direct manipulation metaphor does not suffice anymore. We need somewhere to put those business rules. -The controller already has clear responsibility, so in keeping with single responsibility principle that's not the place for the behaviour. -The traditional OO answer is to put the behaviour into the model, but that leads to hard-to-follow logic jumping back and forth in the model objects, and (gark) up and down long inheritance chains. Moreover it turns out that a given domain object will play different roles over times. I.e. the object doesn't need just one behaviour, it needs several, and even worse it needs different behaviours over time. There goes SRP again, only this time in the "intelligent model".

Roles and Contexts to Fill the Gap
So we need something more than MVC: The view is not the place for the behaviour, the model is not the place for the bahivour, and the controller is not the place for it either. This is where roles as separate things come into play. We want explicit roles. We want those business rules implemented in the roles. And we want to assing those roles to domain objects as needed.

The role a given object plays at a given moment depends on the context at that moment. So why not introduce contexts as something explict along with the explicit roles? Together roles implementing behaviour and contexts assigning roles to objects fill the gap in MVC.

Back to APS.NET MVC
Lets get practical: Where do the contexts and the roles go then? Since the contexts manage assigning roles and kicking off the behaviuour the contexts and roles fit well together. In the ASP.NET MVC + DCI demo I did for ANUG I organized the code like this:

The Contexts folder has a subfolder for the use case I demoed. Other use cases would have their own subfolders. Inside the subfolder is the context for executing that use case, and the associated roles.

What is a role in C#? A role in C# is a set of extension methods on an interface (see this and that for more on roles in C#):

    1     public static class TransferMoneySourceTrait
    2     {
    3         public static void TransferTo(this TransferMoneySource self, TransferMoneySink recipient, decimal amount)
    4         {
    5             // The implementation of the use case
    6             if (self.Balance < amount)
    7             {
    8                 throw new ApplicationException(
    9                     "insufficient funds");
   10             }
   11 
   12             self.Withdraw(amount);
   13             self.Log("Withdrawing " + amount);
   14             recipient.Deposit(amount);
   15             recipient.Log("Depositing " + amount);
   16         }
   17     }

How does the context track the role assignments? Simple:

    8     public class TransferMoneyContext
    9     {
   10         public TransferMoneySource Source { get; private set; }
   11         public TransferMoneySink Sink { get; private set; }
   12         public decimal Amount { get; private set; }
   13 
   14         public TransferMoneyContext(TransferMoneySource source, TransferMoneySink sink, decimal amount)
   15         {
   16             Source = source;
   17             Sink = sink;
   18             Amount = amount;
   19         }
   20 
   21         public void Execute()
   22         {
   23             Source.TransferTo(Sink, Amount);
   24         }
   25     }
   26 

Where are the objects mapped to roles? Right in the seam between the controller and the context (lines 35 to 37):

   11     public class TransferMoneyController : Controller
   12     {
   13         AccountRepository accountRepo = new AccountRepository();
   14 
   15         public ActionResult Index()
   16         {
   17 
   18             ViewData["SourceAccounts"] =
   19                 accountRepo.Accounts.Select(a => new SelectListItem {Text = a.Name, Value = a.Id.ToString()});
   20             ViewData["DestinationAccounts"] =
   21                 accountRepo.Accounts.Select(a => new SelectListItem {Text = a.Name, Value = a.Id.ToString()});
   22             return View();
   23         }
   24 
   25         [AcceptVerbs(HttpVerbs.Post)]
   26         public ActionResult Index(FormCollection form)
   27         {
   28             var sourceAccountId = form["SourceAccounts"];
   29             var destinationAccountId = form["DestinationAccounts"];
   30             var amount = form["Amount"];
   31 
   32             var sourceAccount = accountRepo.GetById(int.Parse(sourceAccountId));
   33             var destinationAccount = accountRepo.GetById(int.Parse(destinationAccountId));
   34 
   35             new TransferMoneyContext(sourceAccount as TransferMoneySource, 
   36                 destinationAccount as TransferMoneySink, 
   37                 decimal.Parse(amount)).Execute();
   38 
   39             ViewData["Amount"] = amount;
   40             ViewData["Source"] = sourceAccount.Name;
   41             ViewData["Destination"] = destinationAccount.Name;
   42 
   43             return View("Result");
   44         }
   45     }

Apart from lines 35 to 37 this is all just standard ASP.NET MVC stuff: Getting data in and out of the ViewData, and returning the view to render back to the user.

Summing Up
MVC is great for simple situations. It doesn't quite scale to complex business scenarios, but DCI does, and the two are a great match.
Leveraging the power of C# to do DCI and the niceness of ASP.NET MVC to go along with it, makes for a - IMHO -very compelling architecte style for an enterprisy web app.

Options for DCI on .NET

2010-12-20T15:03:00.015+01:00

Here's a short summary of the technical/language options for doing DCI on the .NET platform. The list below is loosely ordered in order of increasing "mainstreamness" - according to me :-).
The list notes the language, how roles and contexts are handled and how the solution is run on .NET.

Scala "cross-compiled" to MSIL/CLR:
In Scala contexts are simply objects instantiated at runtime from context classes. The contexts have the responsibility of instantiating data objects and mapping roles to them. Roles are traits that are mixed into data objects at instantiation time. So typically the contexts receive ids for data objects, pull the corresponding data from e.g. a database, and instantiate the data object with a role trait mixed in. In Scala this is all strongly typed and looks like this:
```
class MoneyTransferContext(sourceAccountId: int,
                            sinkAccountId: int){
   val source =
        new SavingsAccount(sourceAccountId) with TransferMoneySource
   val sink =
         new CheckingAccount(sinkAccountId) with TransferMoneySink
   def execute = {
     source.deposit(100000)
     source.transferTo(200, sink)
     }
}
```
To run this in a .NET setting the Scala code must "cross-compiled" to MSIL, and must use the .NET standard library along with the Scala APIs. For details on this see my earlier post, or the introduction on the Scala language web site.

Python running on IronPython:
In Python contexts are objects, that take the responsibility of mixing roles into data objects dynamically. The data objects can be instantiated outside the context or inside the context depending on taste. When the context is done the roles can be yanked back out of the data objects. I dont know a whole lot of Python, so I wont go into details, but refer you to Serge Beaumonts sample.
To run this on .NET use IronPython.

Ruby running on IronRuby:
In Ruby contexts are also objects, that take the responsibility of mixing roles into data objects dynamically. Data objects can be instantiated inside the context or outside the context. Roles in Ruby are implemented as modules, which using the Ruby standard library can be mixed into any Ruby object. The Ruby code looks like this:

class TransferMoneyContext
   attr_reader :source_account, :destination_account, :amount
   include ContextAccessor
   
   def self.execute(amt, source_account_id, destination_account_id)
     TransferMoneyContext.new(amt, source_account_id,
                              destination_account_id).execute
   end
 
   def initialize(amt, source_account_id, destination_account_id)
     @source_account = Account.find(source_account_id)
     @source_account.extend MoneySource
     @destination_account = Account.find(destination_account_id)
     @amount = amt
   end

   def execute
     in_context do
       source_account.transfer_out
     end
   end

end

To run this on .NET just use IronRuby. It runs fine out of the box.

C# and Dynamic:
Using the dynamic features of C#, contexts are objects that receive either data objects or IDs of data objects. In case of an ID the context instantiates the data object and populates it based on the ID and some data source. In both cases the data object has a role reference which will point to an expando object, into which the roles methods are injected. The code looks roughly like this:
```
dynamic transfer = new ExpandoObject();
 transfer.Transfer = (Action)
  ((source, sink, amount) =>{ 
    dynamic mSource = source;
    dynamic mSink = sink;
    mSource.DecreaseBalance(amount);
    mSink.IncreaseBalance(amount);});
 Account sourceAcct = new Account { CashBalance = 100m };
 sourceAcct.Role = transfer;
 Account sinkAcct = new Account { CashBalance = 50m };
 sourceAcct.Role.Transfer(sourceAcct,sinkAcct,10m);
```
Running on .NET? Well, it's C#, so just do it.

C# and extention methods:
Using C# extension methods for roles contexts are objects that receive either data objects or IDs of data objects. In either case the context maps the data objects to roles. Roles are implemented as static classes containing extension methods for role interfaces. Data objects capable of playing a given role implement that role interface. The code looks like this:
public class TransferMoneyContext { public TransferMoneySource Source { get; private set; } public TransferMoneySink Sink { get; private set; } public decimal Amount { get; private set; } public TransferMoneyContext(TransferMoneySource source, TransferMoneySink sink, decimal amount) { Source = source; Sink = sink; Amount = amount; } public void Execute() { Source.TransferTo(Sink, Amount); } } public interface TransferMoneySink { void Deposit(decimal amount); void Log(string message); } public interface TransferMoneySource { decimal Balance { get; } void Withdraw(decimal amount); void Log(string message); } public static class TransferMoneySourceTrait { public static void TransferTo(this TransferMoneySource self, TransferMoneySink recipient, decimal amount) { // The implementation of the use case if (self.Balance < amount { throw new ApplicationException("insufficient funds"); } self.Withdraw(amount); self.Log("Withdrawing " + amount); recipient.Deposit(amount); recipient.Log("Depositing " + amount); } }

How to run this on .NET is ... well ... pretty obvious :-)

RHoK'ing for Unicef

2010-12-06T19:39:00.000+01:00

I was at the RHoK 2.0 Aarhus event this weekend, and got the opportunity to do a simple little web app for Unicef. The app itself is not that interesting for people outside of Unicef, but it will save real money for Unicef that they can use on something else...like helping children. The app is something like 80% done, and we did it in about 28 hours. Wow, it feels great to have been able to actually help Unicef just by doing a saturday to sunday hackathon along with a few other geeks.

The app was done in ASP.NET MVC 2, with Enitity Framework 4 and SQL Express underneath, and the experience was pretty good: The architecture just came out of the box with MVC. EF code first made thinking about the database schema a non-issue (and the load on the app is expected to be low, so I don't think will need to go in a tweak for performance later). We were able to get by with some of the auto generated CRUD views that Visual Studio can make for ASP.NET MVC model objects. All in all the development was pretty quick.
The code is on google code.

Slides from DCI talk at ANUG

2010-11-26T06:22:00.001+01:00

I did a talk on DCI at my local .NET User Group, ANUG, the other night and had a great time. The slides from the talk were:

DCI ANUG - 24th November 2010

View more presentations from c_horsdal.

The slides were followed by three demos:

A simple Scala example "cross"-compiled to run on .NET
A simple Ruby example running on IronRuby
A slightly larger ASP.NET MVC based C# example, which I will be posting details about in the furture.

Upcoming events

2010-11-16T22:28:00.000+01:00

I just wanted to point to 2 events that are coming up soon that I am participating in:

I am doing a talk on DCI in the Aarhus .NET User Group on the 24th of November 2010. Register at http://on.fb.me/9QOa3s
I am participating in Random Hacks of Kindness during the weekend 4th and 5th of December 2010. More info and registration at: http://rhokaarhus.eventbrite.com/

A Pinch of Functional in my C# - An Everyday Example

2010-10-14T21:44:00.000+02:00

I'm working on a codebase that, like many other code bases, has a number of data access objects(DAOs) that all inherit a common superclass. The other day I got tired of looking this pattern of code repeated a lot in the DAOs:

    1        public MyDTO GetMyDTO(...)
    2         {
    3             DataContext DB = NewDBContext;
    4             try
    5             {
    6                 DB.Connection.Open();
    7                 //Fetch something from the DB and return it
    8             }
    9             finally
   10             {
   11                 if (DB.Connection.State == ConnectionState.Open)
   12                     DB.Connection.Close();
   13             }
   14         }

I wanted the creation of the DBContext and the handling of the connection to be factored into somewhere reusable. So I applied the functional "suround with" pattern and introduced this method in the superclass:

    1        protected TReturn UsingDBConnection<TReturn>(Func<DataContext, TReturn> func)
    2         {
    3             DataContext DB = NewDBContext;
    4             try
    5             {
    6                 DB.Connection.Open();
    7                 return func(DB);
    8             }
    9             finally
   10             {
   11                 if (DB.Connection.State == ConnectionState.Open)
   12                     DB.Connection.Close();
   13             }
   14         }

and the DAO code then turns into this:

    1        public MyDTO GetMyDTO(...)
    2         {
    3             return UsingDBConnection(DB =>
    4             {
    7                 //Fetch something from the DB and return it
    7             });
    8         }

C# has supported this for years now, so why am I posting it? -Because I wish I saw more of this type of code. To me it's easy to read and I get to reuse the common part.

Notes from getting Scala running on .NET

2010-10-02T21:03:00.000+02:00

I just spend an evening getting Scala to run on .NET 4.0. Here my notes:

Scala 2.8.0

I started downloading Scala 2.8.0-final as a zip file (), and unpacking it to my scala playground directory. That gave me:

PS C:\Scala-playground\scala-2.8.0.final> tree
Folder PATH listing for volume OSDisk
Volume serial number is 00690066 6A5B:A532
C:.
+---bin
+---doc
¦   +---sbaz
¦   +---sbaz-setup
+---lib
+---meta
¦   +---cache
+---misc
¦   +---sbaz
¦   ¦   +---config
¦   ¦   +---descriptors
¦   +---sbaz-testall
¦   ¦   +---tests
¦   +---scala-devel
¦   ¦   +---plugins
¦   +---scala-tool-support
¦       +---a2ps
¦       +---bash-completion
¦       +---bluefish
¦       +---context
¦       ¦   +---Highlighters
¦       ¦   +---Template
¦       +---emacs
¦       ¦   +---contrib
¦       +---enscript
¦       +---geshi
¦       +---intellij
¦       +---jedit
¦       ¦   +---console
¦       ¦   ¦   +---commando
¦       ¦   +---modes
¦       +---latex
¦       +---notepad-plus
¦       +---scite
¦       +---subethaedit
¦       ¦   +---artwork
¦       ¦   +---Scala.mode
¦       ¦       +---Contents
¦       ¦           +---Resources
¦       ¦               +---English.lproj
¦       ¦               +---Scripts
¦       +---textmate
¦       ¦   +---Bundles
¦       +---textpad
¦       +---textwrangler
¦       +---ultraedit
¦       +---vim
¦           +---ftdetect
¦           +---indent
¦           +---plugin
¦           +---syntax
+---src

I then went on to install the Scala msil extension (i.e. the scala .NET compiler and runtime) as follows:

PS C:\Scala-playground\scala-2.8.0.final> bin/sbaz.bat install scala-msil

Then, following the "official" instructions on running scala on .NET (http://www.scala-lang.org/node/168), I copied mscorlib.dll to the scala lib folder:

PS C:\Scala-playground\scala-2.8.0.final> copy C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll .\lib

I was now ready to try to compile something. E.g. this very simple hello world program using a little bit of .NET, namely Console.WriteLine:

import System.Console

object test extends Application {
  Console.WriteLine("Hello world!")
}

I tried to compile it like this:

PS C:\Scala-playground\hello.net> ..\scala-2.8.0.final\bin\scalac.bat -target:msil .\test.scala

but got this error:

scala.tools.nsc.MissingRequirementError: class scala.runtime.VolatileBooleanRef not found.
        at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:513)
        at scala.tools.nsc.symtab.Definitions$definitions$.getClass(Definitions.scala:471)
        at scala.tools.nsc.symtab.Definitions$definitions$.newValueClass(Definitions.scala:620)
        at scala.tools.nsc.symtab.Definitions$definitions$.BooleanClass(Definitions.scala:92)
        at scala.tools.nsc.symtab.Definitions$definitions$.initValueClasses(Definitions.scala:643)
        at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:787)
        at scala.tools.nsc.Global$Run.(Global.scala:597)
        at scala.tools.nsc.Main$.process(Main.scala:107)
        at scala.tools.nsc.Main$.main(Main.scala:122)
        at scala.tools.nsc.Main.main(Main.scala)
error: fatal error: class scala.runtime.VolatileBooleanRef not found.

I tried like this to point out where mscorlib and the scala runtime dlls are:

PS C:\Scala-playground\hello.net> ..\scala-2.8.0.final\bin\scalac.bat -target:msil -Xassem-extdirs ..\scala-2.8.0.final\lib .\test.scala
scala.tools.nsc.MissingRequirementError: class scala.runtime.VolatileBooleanRef not found.
        at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:513)
        at scala.tools.nsc.symtab.Definitions$definitions$.getClass(Definitions.scala:471)
        at scala.tools.nsc.symtab.Definitions$definitions$.newValueClass(Definitions.scala:620)
        at scala.tools.nsc.symtab.Definitions$definitions$.BooleanClass(Definitions.scala:92)
        at scala.tools.nsc.symtab.Definitions$definitions$.initValueClasses(Definitions.scala:643)
        at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:787)
        at scala.tools.nsc.Global$Run.(Global.scala:597)
        at scala.tools.nsc.Main$.process(Main.scala:107)
        at scala.tools.nsc.Main$.main(Main.scala:122)
        at scala.tools.nsc.Main.main(Main.scala)
error: fatal error: class scala.runtime.VolatileBooleanRef not found.

..same error.

Then I resorted to frantic googling, but ended up deciding to downgrade the mscorlib.dll to 2.0, and to 1.1. But in both cases I got same depressing result.
Finally I decided to downgrade to scala 2.7.7.

Scala 2.7.7

I downloaded scala 2.7.7 unzipped it and got:

PS C:\Scala-playground\scala-2.7.7.final> tree
Folder PATH listing for volume OSDisk
Volume serial number is 00690066 6A5B:A532
C:.
+---bin
+---doc
¦   +---sbaz
¦   +---sbaz-setup
+---lib
+---meta
¦   +---cache
+---misc
¦   +---sbaz
¦   ¦   +---descriptors
¦   +---sbaz-testall
¦   ¦   +---tests
¦   +---scala-tool-support
¦       +---a2ps
¦       +---bluefish
¦       +---context
¦       ¦   +---Highlighters
¦       ¦   +---Template
¦       +---emacs
¦       ¦   +---contrib
¦       +---enscript
¦       +---geshi
¦       +---intellij
¦       +---jedit
¦       ¦   +---console
¦       ¦   ¦   +---commando
¦       ¦   +---modes
¦       +---latex
¦       +---notepad-plus
¦       +---scite
¦       +---subethaedit
¦       ¦   +---artwork
¦       ¦   +---Scala.mode
¦       ¦       +---Contents
¦       ¦           +---Resources
¦       ¦               +---English.lproj
¦       ¦               +---Scripts
¦       +---textmate
¦       ¦   +---Bundles
¦       +---textpad
¦       +---textwrangler
¦       +---ultraedit
¦       +---vim
¦           +---ftdetect
¦           +---indent
¦           +---plugin
¦           +---syntax
+---src

The I went through copying mscorlib and installing scala-msil again:

PS C:\Scala-playground\scala-2.7.7.final> copy C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll .\lib
PS C:\Scala-playground\scala-2.7.7.final> .\bin\sbaz.bat install scala-msil
planning to install: scala-msil/2.7.7.final
Installing...

Then I tried compilling again:

PS C:\Scala-playground\hello.net> ..\scala-2.7.7.final\bin\scalac-net.bat .\test.scala
PS C:\Scala-playground\hello.net> ls


    Directory: C:\Scala-playground\hello.net


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        30-09-2010     21:59            target
-a---        30-09-2010     22:33       3863 test.msil
-a---        30-09-2010     21:52        100 test.scala

which went well. The scala compiler made a .msil file. Yeah.

Next step was turning that .msil into an .exe:

PS C:\Scala-playground\hello.net> C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe .\test.msil

Microsoft (R) .NET Framework IL Assembler.  Version 4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembling '.\test.msil'  to EXE --> '.\test.exe'
Source file is ANSI

Assembled method test::$tag
Assembled method test::main
Assembled method test$::.ctor
Assembled method test$::.cctor
Assembled method test$::$tag
Assembled method test$::main
Assembled global method Main
Creating PE file

Emitting classes:
Class 1:        test
Class 2:        test$

Emitting fields and methods:
Global  Methods: 1;
Class 1 Methods: 2;
Class 2 Fields: 1;      Methods: 4;
Resolving local member refs: 8 -> 8 defs, 0 refs, 0 unresolved

Emitting events and properties:
Global
Class 1
Class 2
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Operation completed successfully

Which gave:

PS C:\Scala-playground\hello.net> ls


    Directory: C:\Scala-playground\hello.net


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        30-09-2010     21:59            target
-a---        30-09-2010     22:35       2560 test.exe
-a---        30-09-2010     22:33       3863 test.msil
-a---        30-09-2010     21:52        100 test.scala

So I tried running the program:

PS C:\Scala-playground\hello.net> .\test.exe

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'predef, Version=0.0.0.0, Culture=
neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
   at Main(String[] args)

but missed the predef assembly which is part of the scala-msil extension. To get passed that I simply copied all dlls from the Scala lib folder and ran again:

PS C:\Scala-playground\hello.net> mv .\test.exe .\target
PS C:\Scala-playground\hello.net> cp ..\scala-2.7.7.final\lib/*.dll .\target
PS C:\Scala-playground\hello.net> cd .\target
PS C:\Scala-playground\hello.net\target> ls

    Directory: C:\Scala-playground\hello.net\target


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        30-09-2010     22:30    2070528 mscorlib.dll
-a---        30-09-2010     22:30    1180160 predef.dll
-a---        30-09-2010     22:30       5632 scalaruntime.dll
-a---        30-09-2010     22:35       2560 test.exe
PS C:\Scala-playground\hello.net\target> .\test.exe
Hello world!

Success! but only on the next to newest Scala version. Either way I had fun :-)

Spec Style Unit Tests in C#

2010-09-25T17:15:00.000+02:00

Spec style unit tests are unit tests that focus on making the specs clear, and then relating some test code to each part of the spec. The Specs Scala unit test framework is really good at that (e.g. check this earlier post), but I want to be able to do the same in C#.

Lets look at an example: A method for deciding whether a given year is a leap year. The rules for leap years are:

A leap year should
   be any year divisible by 400
   but not other years divisible by 100
   and all other years divisible by 4

In other words the above are the specs for the method. So I would like that to be clear from the unit test. I would also like the unit test to make it clear what test code corresponds to what part of the spec. Therefore I would like the spec to be part of the test, and the test code to be mixed right into that spec text. Something like:

"A leap year" should
{
  "be any year divisible by 400" asIn
{
// test code here
}
  "but not other years divisible by 100" asIn
{
// test code here
}
  "and all other years divisible by 4" asIn
{
// test code here
}
}

such that the spec is clearly visible as the strings, and such that the 'asIn' indicates that the code in the following scope tests the part of the spec right before the 'asIn'. To achieve something close to this I've made three simple extension methods on string: 'should', 'asIn' and 'andIn'. Each one of these extension methods take a delegate as an argument. That makes it possible to write this code:

   16             "A leap year".should(() =>
   17             {
   18                 "be any year divisible by 400".asIn(() =>
   19                 {
   20                     // Test code here
   21 
   22                 })
   23                 .andIn(() =>
   24                 {
   25                     // More test code
   26                 });
   27 
   28                 "but not other years divisible by 100".asIn(() =>
   29                 {
   30                     // Test code here
   31                 });
   32 
   33                 "and all other years divisible by 4".asIn(() =>
   34                 {
   35                     // Test code here
   36                 })
   37 

Because this is C# there I need to the dots and the arrows ( ()=> ) in there, but I still think the spec is pretty clearly visible. The extension methods themselves are very simple: They basically just execute the delegate passed to them, which means that all the test code snippets in the above will be executed. The complete code for the extension methods is:

 



    1 using System;
    2 
    3 namespace Specs
    4 {
    5     public static class SpecExtensions
    6     {
    7         public static void should(this string unitUnderTest, 
    8                                   Action executableSpecification)
    9         {
   10             Console.WriteLine(unitUnderTest + " should");
   11             executableSpecification();
   12         }
   13 
   14         public static string asIn(this string readableSpecification,
   15                                   Action executableSpecification)
   16         {
   17             Console.WriteLine(@"    " + readableSpecification);
   18             return RunExecutableSpecification(
   19                     readableSpecification, executableSpecification);
   20         }
   21 
   22         public static string andIn(
   23             this string readableSpecification,
   24             Action executableSpecification)
   25         {
   26             return RunExecutableSpecification(
   27                     readableSpecification, executableSpecification);
   28         }
   29 
   30         private static string RunExecutableSpecification(
   31             string readableSpecification,
   32             Action executableSpecification)
   33         {
   34             executableSpecification();
   35             return readableSpecification;
   36         }
   37     }
   38 }

Combining that with NUnit, the test for my leap year checker becomes:

 


    1 using NUnit.Framework;
    2 
    3 namespace Specs.Test
    4 {
    5     [TestFixture]
    6     public class LeapYearTest
    7     {
    8         [Test]
    9         public void LeapYearSpec()
   10         {
   11             "A leap year".should(() =>
   12             {
   13                 "be any year divisible by 400".asIn(() =>
   14                 {
   15                     Assert.That(LeapYearChecker.IsLeapYear(0),
   16                                 Is.True);
   17                     Assert.That(LeapYearChecker.IsLeapYear(400),
   18                                 Is.True);
   19                     Assert.That(LeapYearChecker.IsLeapYear(800),
   20                                 Is.True);
   21                 })
   22                 .andIn(() =>
   23                 {
   24                     Assert.That(LeapYearChecker.IsLeapYear(-400),
   25                                 Is.False);
   26                 });
   27 
   28                 "but not other years divisible by 100".asIn(() =>
   29                 {
   30                     Assert.That(LeapYearChecker.IsLeapYear(100),
   31                                 Is.False);
   32                     Assert.That(LeapYearChecker.IsLeapYear(100),
   33                                 Is.False);
   34                     Assert.That(LeapYearChecker.IsLeapYear(200),
   35                                 Is.False);
   36                     Assert.That(LeapYearChecker.IsLeapYear(1000),
   37                                 Is.False);
   38                 });
   39 
   40                 "and all other years divisible by 4".asIn(() =>
   41                 {
   42                     for (int i = 0; i < 100; i += 4)
   43                     {
   44                         Assert.That(LeapYearChecker.IsLeapYear(i),
   45                                     Is.True);
   46                     }
   47                 })
   48                 .andIn(() =>
   49                 {
   50                     for (int i = 1600; i < 1700; i += 4)
   51                     {
   52                         Assert.That(LeapYearChecker.IsLeapYear(i),
   53                                     Is.True);
   54                     }
   55                 })
   56                 .andIn(() =>
   57                 {
   58                     for (int i = 1601; i < 1700; i += 4)
   59                     {
   60                         Assert.That(LeapYearChecker.IsLeapYear(i),
   61                                     Is.False);
   62                     }
   63                 });
   64             });
   65         }
   66     }
   67 

The specs are not as easily visible once all the code is there, but I still think its easy to find the specs. What do you think? Is there too much clutter of dots and arrows and stuff? Is the calling back and forth between the test and extension methods too strange? I'm on the fence. One part me really, really likes this. One part of me really, really doesn't.
Oh, and for completeness the code under test is:

 


    1    public static class LeapYearChecker
    2     {
    3         public static bool IsLeapYear(int year)
    4         {
    5             return year >= 0 &&
    6                 (year % 400 == 0 ||
    7                 (year % 4 == 0 && year % 100 != 0));
    8         }
    9     }