Wednesday 31 December 2008

Agile Parenting

Can agile be applied to parenting? I think so. Earlier today, my seven-year old daughter told me she found doing joined-up writing hard. My answer? If something is hard, do it more often.

I think I may need a holiday, oh, I am on holiday.

Happy new year.

Monday 22 December 2008

Assert Yourself

With my current role involving a long train journey, I have taken the opportunity to re-read Kent Beck's Test-Driven Development, By Example. Its one of my favourite technical books, and manages to provide a lot of useful information in quite a small tome. Although the examples are in Java and Python (both of which I have no experience of) I have no problem following them at all. I highly recommend it to anyone who is learning or using TDD.

The book contains many ideas on how to implement and apply TDD, some of which I had forgotten. One such forgotten idea is Assert First. The idea is that when you are writing a test method, the first thing you should write is the Assert statement. You can then work backwards from here to act and then arrange your test. It has a beautiful symmetry with the test first philosophy.

I've been using Assert First quite a lot recently and have found it a very useful addition to my toolbox. It is particularly useful when you are writing the first test of a fixture and are unsure of how to proceed. Many times, in this situation, you know what the results should be but don't know how to get there. Assert first allows you to express your results and then rapidly work towards the solution with confidence.

Monday 15 December 2008

NUnit Tip: Rerun Tests After Each Build

This may be one of those tips where everyone else is like, "Duh? You didn't know that?". But its a great tip, so (at the risk of ridicule) I'll present it anyway.

You can set up the NUnit GUI application so that it re-runs the last test run after each build. If, like me, you have a dual screen setup, then you can do a build in Visual Studio on one screen and immediately see the test results in NUnit GUI on the other screen without having to do any task switching. I'm finding this a great time saver.

To set this up:
  1. Launch the NUnit GUI
  2. From the main menu select Tools | Options
  3. Select "Assembly Reload" from the left hand side
  4. Check the "Reload when test assembly changes" checkbox
  5. Check the "Re-run last tests run" checkbox

Sunday 14 December 2008

Using TDD and Resharper to Learn Something New

This week, I have been working on building RSS feeds from objects in our domain model. I am using System.ServiceModel.Syndication to do the RSS/Atom formatting, so all I needed to worry about is the mapping between domain and the SyndicationItem.

Until recently I would have used XML (along with all its angle bracket evilness) to achieve this. However, I am becoming increasingly disillusioned with using XML for configuration because of the difficulty in testing and reading it. So, having been inspired by Fluent NHibernate and the fluent configuration of Unity, I decided that I would do the mapping using a fluent style. I was aiming for an API that would let me do something like:

var doc = Repository.FetchDocument(someDocId);

var map = new SyndicationItemMapping
{
Title = doc => doc.Filename,
Summary = doc => doc.Body.Substring(0,100),
Content = doc => doc.Body,
Copyright = doc => "(c) 2008. All rights reserved"
};

var syndicationItem = map.From(doc);

I haven't done enough functional programming yet for all the concepts to have fully gelled in my head. I'm quite happy writing lamba expressions but I still struggle with the syntax for the Action<T> and Func<T> delegates that consume them. I knew (or thought I knew) that I was in for a tough couple of hours.

TDD teaches us that when we get stuck like this we should write a test. I knew the kind of API I wanted, so it took me just a few moments to compose a test:

[Test]
public void MapsTitleFromAnEntity()
{
var entity = new MockEntity { Name = "entity name"};
var mapper = new SyndicationItemMapper<MockEntity>
{
Title = entity => entity.Name
};
var syndicationItem = mapper.From<MockEntity>(entity);
Assert.That(syndicationItem.Title, Is.EqualTo(entity.Name));
}
This is where the magic of ReSharper kicked in. A couple of [Alt]+[Enter]'s in the right places generated the code for my SyndicationItemMapper class in a matter of seconds:

public class SyndicationItemMapper<T>
{
public Func<T> string Title { get; set;}

public SyndicationItem From(T entity)
{
throw new NotImplementedException();
}
}
So within a matter of about ten minutes, I had the outline of my implementation and know immediately how I was going to progress. I then completed the implementation for that test and added a few more tests with their implementations. In just over an hour I had built the entire mapping.

Now the point of this post, is not to show how easy it was to build fluent interfaces (although when I compare the time this took compared to all the time it would have take me to build all the XML wotsits I'd have needed, its really quite impressive). No, the point is how TDD helped me to quickly learn some syntax I was unfamiliar with.

Before TDD I would probably have written a [button 1] test harness and then spent hours floundering around trying to find the correct solution (and may well not of). But with the test case I had some solid syntax to aim for and could get the implementation within a couple of hours. Add in the power of Resharper and I was able to get the basic implementation done in a matter of minutes.