dave^2 = -1

ReSharper Live Template for Dependency Properties (C#)

2009-06-27T21:38:00.004+10:00

The syntax for declaring WPF dependency properties can get a little tedious to type. I ended up creating a ReSharper Live Template which has been working nicely for me:

public static readonly DependencyProperty $PropertyName$Property = 
    DependencyProperty.Register("$PropertyName$", typeof($PropertyType$), typeof($PropertyOwner$));

public $PropertyType$ $PropertyName$ {
    get { return ($PropertyType$) GetValue($PropertyName$Property); }
    set { SetValue($PropertyName$Property, value); }
}

Then configure the substitutable variables as follows:

PropertyName, no macro, #3 editable
PropertyType, Guess type expected at this point, #2 editable
PropertyOwner, Containing type name, not editable

This lets me type in dp and fill in the blanks. Hope this helps. :)

Occasional trouble mocking generic methods

2009-06-17T00:00:00.000+10:00

I've seen a few people get bitten by an edge case of using generics with mocking frameworks. Let's look at a contrived example and see what's going on. We're using Rhino Mocks 3.5 in this case, but the symptoms described here are not specific to that mocking framework, but rather are related to how generics work in .NET.

public interface IFish{}
public class Eric : IFish{}
public interface IAquarium {
    IEnumerable<T> FindEverythingLike<T>(T thisThing);
}

[Test]
public void LookingForALicenceForMyPetFishEric() {
    var petFish = new Eric();
    var expectedErics = new[] {petFish};

    IAquarium stubAquarium = MockRepository.GenerateStub<IAquarium>();
    stubAquarium
        .Stub(aquarium => aquarium.FindEverythingLike(Arg<IFish>.Is.Anything))
        .Return(expectedErics);

    var actualErics = stubAquarium.FindEverythingLike(petFish);
    Assert.That(actualErics, Is.EqualTo(expectedErics));
}

Here we're asking our stubbed IAquarium to return an expectedErics array whenever it gets any IFish as an argument to the generic FindEverythingLike<T>() method. We then pass our petFish to the method and get the actual enumerable returned from our stub. So what does this assertion give us?

MockingGenerics.LookingForALicenceForMyPetFishEric : FailedNUnit.Framework.AssertionException:   Expected: < <Workshop.Tests.Eric> >
  But was:  null

Oops, our stubbed value hasn't been returned. Our petFish is an instance of class Eric, which implements IFish, so why isn't our stub returning our expectedErics?

The reason for this is that we are actually stubbing out FindEverythingLike<IFish>(), but are calling FindEverythingLike<Eric>(). While we declare this as a single generic method, the CLR actually calls these as two completely different method instances. This is obscured a bit by the fact that type inference is used to determine which method instance is called. If we don't rely on type inference we can get the test to pass:

    var actualErics = stubAquarium.FindEverythingLike<IFish>(petFish);
    Assert.That(actualErics, Is.EqualTo(expectedErics));

In the real examples where I've seen errors like this we generally have more collaborators involved and the problem becomes harder to detect. It's not a common case, requiring us passing different static types to a generic method where at first glance it looks reasonable to expect our call to resolve to the one method.

Just to belabour the point for one more example, let's just confirm that it is the static type of our reference that determines which method instance is called, rather than the actual instance type:

[Test]
public void GenericsAndMockingCanBeTroublesome() {
    IAquarium mockAquarium = MockRepository.GenerateMock<IAquarium>();    
    Eric petFish = new Eric();
    IFish sameFish = petFish;

    mockAquarium.FindEverythingLike(petFish);
    mockAquarium.AssertWasCalled(aquarium => aquarium.FindEverythingLike(sameFish));
}

This case fails, as we are calling mockAquarium.FindEverythingLike<Eric>(), but asserting that FindEverythingLike<IFish>() was called. Even though it is the same instance, the declared types of each reference at compile time are the ones that are used to dispatch to our generic method instance.

Hope this helps save someone a couple of minutes of frustration. :)

Scenario-based unit testing post in PDF format

2009-06-11T23:10:00.002+10:00

My last post on Moving to scenario-based unit testing in .NET was pretty long, even for me. I've just gone and done a rough conversion of it to PDF, so if you felt the topic was vaguely interesting but were put off by having to scroll through loads of my aesthetically-challenged blog screens, then feel free to give the PDF a go. I feel it would have really helped me had I read it a year or so ago, so I thought I'd put it in a more readable format to try and encourage someone else to actually read it. :)

Unfortunately the conversion process didn't improve the actual content of the post, so you'll still have to bear with my insufferable ramblings if you decide to subject yourself to it. ;)

Download as PDF: MovingToScenarioBasedTesting.pdf

Moving to scenario-based unit testing in .NET

2009-06-10T22:29:00.006+10:00

This post is pretty long, even for me. You can download it as a PDF file (roughly converted) which might be a bit easier to read. Unfortunately the conversion process didn't improve the actual content of the post, so you'll still have to bear with my insufferable ramblings if you decide to subject yourself to it. ;)

Download as PDF: MovingToScenarioBasedTesting.pdf

From my observations most developers (myself included) start writing tests using one testcase class per class under test. Due to an unfortunate attribute naming choice, NUnit users may know this as "fixture per class", and implement it as one class marked [TestFixture] holding all the tests that relate to one production class.

I think the reason this approach is so common is because introductory testing and TDD examples tend to focus on smallish utilities like stacks or basic calculators, where fixture setups and object interactions tend not to get out of hand. In my experience, taking the knowledge learned during from basic examples and trying to apply them to Real Life^TM ends in pain, frustration, nausea, alcoholism and, in rare cases, spontaneous human combustion. Even worse, it may cause developers to abandon writing unit tests altogether!

There are many alternatives for organising tests (testcase class per fixture, feature, method, etc.), but the one I've found easiest to adopt and use is a testcase class per scenario. We've been using this at work across two teams for a few months now, and while not perfect it does seem to make writing, reading and maintaining tests relatively easy. In fact, I'm 99% sure that learning to write tests in this way initially (rather than the usual testcase class per class way) would avoid most of the problems we face when first trying to adopt unit testing and test driven development.

The aim of this post is to describe what on earth I'm talking about, as well as how to move from testcase class per class to scenario-based testcase classes, and also outline some of the unresolved problems we've run into with this approach.

A note on terminology

I'm probably drastically misusing terminology here when I talk about scenario-based testing. The way I'm using the term "scenario" seems quite different to scenario-based testing as described in Wikipedia, but I don't know a better name for it. The word "scenario" is used a lot when talking about Behaviour Driven Development (BDD) as well, but I wouldn't be so presumptuous to think this approach qualifies as BDD. It doesn't really seem to match the Dan North or Dave Astels definitions. Instead, I'd appreciate it if we ignore the terminology and just focus the basic ideas -- you can substitute whatever terminology you like! :)

The example

Let's look at the traditional way of introducing testing concepts -- a contrived example. Say we've been contracted by KAOS, an private company with a strong focus on research and development. Their latest project is something they casually refer to as The Doomsday Device. KAOS, being an agile sort of organisation, have given us some simple stories:

The screen should display a welcome message to the agent using the Doomsday Device.
The user can click a button to fire the Doomsday Device
After firing, the user cannot click the button again until the Doomsday Device has finished its firing sequence

Seems fairly easy. We'll use a Model View Presenter style approach so we can test this logic without actually firing the device. Siegfried, the product owner, has assured us that the consequence of any bugs could be quite dire. He stresses "Vee are KAOS agents -- vee don't write bugs here!".

Testcase class per class

We start off by creating a DoomsDayDevicePresenterFixture, and then begin writing tests and filling in passing implementations. Here is what our fixture looks like when we're done:

/* Fixture per class example */
[TestFixture]
public class DoomsDayDevicePresenterFixture {
    private IDoomsDayDeviceView stubView;
    private IDoomsDayDevice stubDoomsDayDevice;

    [SetUp]
    public void SetUp() {
        stubView = MockRepository.GenerateStub<IDoomsDayDeviceView>();
        stubDoomsDayDevice = MockRepository.GenerateStub<IDoomsDayDevice>();
        new DoomsDayDevicePresenter(this.stubView, this.stubDoomsDayDevice);
    }

    private void RaiseLoadedEventOnView() {
        stubView.Raise(view => view.Loaded += null, this, EventArgs.Empty);
    }
    private void RaiseFireButtonPressedOnView() {
        stubView.Raise(view => view.FireButtonPressed += null, this, EventArgs.Empty);
    }
    private void RaiseFiringCompletedOnDevice() {
        stubDoomsDayDevice.Raise(device => device.FiringCompleted += null, this, EventArgs.Empty);
    }

    [Test]
    public void ShouldWelcomeEvilAgentWhenLoaded() {
        const String agentsName = "Siegfried";
        stubDoomsDayDevice
            .Stub(device => device.CurrentOperatorsName())
            .Return(agentsName);
        RaiseLoadedEventOnView();
        Assert.That(stubView.WelcomeMessage, Is.EqualTo("Welcome KAOS Agent " + agentsName + ". What would you like to destroy today?"));
    }

    [Test]
    public void ShouldEnableFireButtonWhenViewLoaded() {
        RaiseLoadedEventOnView();
        Assert.That(stubView.FireButtonEnabled, Is.True);
    }    

    [Test]
    public void FireButtonShouldFireDoomsDayDevice() {
        RaiseLoadedEventOnView();
        RaiseFireButtonPressedOnView();
        stubDoomsDayDevice.AssertWasCalled(device => device.Fire());
    }

    [Test]
    public void ShouldDisableFireButtonWhileFiring() {
        RaiseLoadedEventOnView();
        RaiseFireButtonPressedOnView();
        Assert.That(stubView.FireButtonEnabled, Is.False);
    }

    [Test]
    public void ShouldEnableFireButtonWhenFiringCompleted() {
        RaiseLoadedEventOnView();
        RaiseFireButtonPressedOnView();
        RaiseFiringCompletedOnDevice();
        Assert.That(stubView.FireButtonEnabled, Is.True);
    }    
}

Our tests all pass. Hooray!

What's wrong with this?

What's wrong with this testcase class? Well, nothing really I guess. It's manageable enough for now. However when we start adding features we may find the lack of cohesion between the tests causes us pain (at least it always has for me. I'm quite happy to acknowledge I could just be doing it wrong).

The main source of the cohesion problem is the setup used for each test. The testcase class has its own setup method, but the first few lines of each test performs some additional setup. In somes cases, such as the ShouldDisableFireButtonWhileFiring() and FireButtonShouldFireDoomsDayDevice(), this setup code is repeated. These two tests are really asserting two facts about the same situation (firing the device), but you can't easily see that from the test code. Test code can be a great way of communicating how your code works, but this lack of cohesion in the setups used can make it really difficult to parse out this information.

Having setup information all over the place can make the test code hard to maintain. Changes like requiring a dependency to provide new data at a different time can cause large numbers of tests to break, especially when they've ended up with setups that don't truly reflect the contexts they use. Well factored tests can be a great enabler of change. Fragile tests have the opposite effect.

One thing you can't see from this example, and to me one of the most important drawbacks, is the impact of this approach on test driven development. Most people I know who have learned/tried to learn TDD (especially when learning without a mentor) have done some of the examples, decided to apply it to a real project, sat down to write the first test and... have absolutely no idea where to start. Should we first test the presenter has wired up the correct events on the view? Should we construct a presenter and see if its null (don't laugh, I've seen it recommended!)? Knowing what tests to write to drive development was probably my greatest hurdle in learning TDD -- it is natural to keep thinking in terms of how we want objects and methods to work, rather than what we want the design to do, which robs you of the design benefits TDD can provide.

Testcase class per fixture?

The setup required for a series of tests is generally called the test fixture -- basically, all the stuff that needs to be in place for the assertions in a test to apply and run successfully. To make managing these tests easier we could break them out into a series of testcase classes per fixture. But then we end up with another problem -- our fixtures overlap. Let's think this through for a moment and see if we can find out why this could pose a problem.

All the tests start with a call to RaiseLoadedEventOnView(), so we could just whack that in the setup and have a fixture for all our tests the rely on the loaded view. Except for the ShouldWelcomeEvilAgentWhenLoaded(), which needs to stub out a value before we raise the loaded event. We could stub the value in the setup method as well, but then we lose the benefit of knowing which functionality relies on having that value available. Following this path leads to an increase in the amount of setup code, most of which doesn't apply to all the tests. This can end up obscuring what we are actually testing.

If we were going to go by fixtures, what would we name them? We have one fixture that stubs an agent name and uses a loaded view, another that just needs a loaded view, two that share a fixture where we have a loaded view and a pressed button, and another that has a loaded view, pressed button, and a firing completed event. Based on fixture alone it's hard to come up with good names here, which is generally a sign that we have the wrong class break down.

When I first looked at moving from testcase class per class, grouping tests by fixture was my first stop. I found I had trouble finding clean slices through the fixtures that would neatly group everything. Even when I thought I had it right, my next test would require a change to a fixture that invalidated the breakdown I had chosen. It seemed like I was getting closer to a good approach, but it was still missing something. It wasn't until some people much smarter than me (although less bloggish :)) got together and came up with a better solution that everything started to click into place.

Testcase class per scenario

The change in thinking was to stop worrying about specific fixtures and setups and to group things by scenario. Bit anti-climatic I know, but the change in thought process seemed to fix the majority of the problems we were facing. By concentrating on scenario, and how our class under test should behave in that scenario, the fixtures naturally became more cohesive. The delineation between scenario-specific fixture setup and test logic became obvious. Fixtures and tests were easy to name, and trivial to write. For the first time I no longer struggled to come up with what to test next. Instead I just picked a scenario and started asserting facts about how my class should behave in that scenario and what state it should have.

Of course, this really just ends up as another way of breaking things down by fixture, which I've spent the entirety of the last section complaining about. But I've found the change in thinking indispensable in getting this to work. It's very hard to establish up front exactly what fixtures you're going to need (which results in a lot of churning of test code), but it is generally fairly obvious what scenarios your objects need to work under. In a way, the nice fixture break down is a nice side-effect that comes out of having well-structure scenarios.

I'm intending to post later on how to start from scratch using this approach, but seeing we've come this far lets look at the steps we can use to break our current testcase class into scenarios. Hopefully this will illustrate why I like this approach so much.

Refactoring toward scenario-based tests

The first step is to identify some scenarios in our existing testcase class. Any name referring to a time or event is a hint about the scenario the test relates to. The word "when" is a dead give-away. Scanning through our current tests I can see two that relate to when the view is loaded (ShouldWelcomeEvilAgentWhenLoaded() and ShouldEnableFireButtonWhenViewLoaded()). We also have ShouldDisableFireButtonWhileFiring(). When is the device firing? Looking at the code in that test, it is when the fire button is pressed. The FireButtonShouldFireDoomsDayDevice() also seems to relate to this scenario. And lastly we have ShouldEnableFireButtonWhenFiringCompleted() -- so when firing completed sounds like a good scenario for that one. (You don't have to identify all the scenarios up front, just enough to get you started.)

The second step is to pick one of the identified scenarios and create a testcase class for it. We can then proceed in a couple of ways. One way is to start moving tests one at a time into our new file that relate to the new scenario. Another is to copy and paste the entirety of the old testcase class into our new file, and start removing things that don't relate to the scenario. We repeat this until all our old test cases are in scenarios.

The final step is to factor out the duplication between our testcase scenarios into helper methods in a common base class or two. You can probably get away with doing this as you go, but I'd advise against doing it too prematurely. Wait until the code in two or three scenarios is screaming to be consolidated, and then do it. Otherwise you can wind up extracting commonalities that aren't really there, and we go back to losing cohesion between our setups and tests.

Let's have a look at the when view is loaded scenario. I'll create a new subfolder in our test project called DoomsDayDevicePresenterScenarios, then create a WhenViewLoaded.cs class. I'm quite a fan of underscore-overload (cue shameless post plug), so I'd prefer to use When_view_loaded, but I'll try and skip potentially heated debates for now. :)

The code below is how it looks after refactoring out some duplication:

namespace DaveSquared.Kaos.Tests.DoomsDayDevicePresenterScenarios {
    public partial class DoomsDayDevicePresenterScenario {
        [TestFixture]
        public class WhenViewLoaded : ScenarioBase {
            const string AgentsName = "Siegfried";

            [SetUp]
            public void SetUp() {
                CreateDoomsDayDevicePresenterAndDependencies();
                stubDoomsDayDevice.Stub(device => device.CurrentOperatorsName()).Return(AgentsName);
                RaiseLoadedEventOnView();
            }

            [Test]
            public void ShouldWelcomeEvilAgent() {
                Assert.That(stubView.WelcomeMessage, Is.EqualTo("Welcome KAOS Agent " + AgentsName + ". What would you like to destroy today?"));
            }

            [Test]
            public void ShouldEnableFireButton() {
                Assert.That(stubView.FireButtonEnabled, Is.True);
            }
        }
    }
}

Look how beautifully simple those tests are -- both one line assertions. And it reads nicely too: when view loaded, should welcome evil agent, and should enable fire button. You'll notice I've committed one of the sins I mentioned in my rantings about testcase class per fixture -- I've stubbed out a value in our setup that doesn't relate to all our tests. There are a couple of reasons that I don't care in this case. First, our setup focuses on what is required for this scenario, and the current agent's name happens to be important to this scenario, even if not to all the tests. I'm still getting good cohesion vibes. Second, I can use constants and properties with decent names to make sure the expected state of the scenario is clear. Thirdly, it just doesn't seem to cause me any troubles in real life, unlike when I tried breaking things down by fixture alone.

You may have noticed a weird partial class thingoe happening here. This was suggested by a colleague to make scenarios more discoverable from within Resharper. If all scenarios related to our presenter are inner classes of the DoomsDayDevicePresenterScenario partial class, then Resharper's "go to type" command (Ctrl + T on my configuration) will let us select the partial class, then list all the scenarios for us to jump to. It adds some code noise, and isn't strictly necessary, but does make navigating around your tests easier.

Let's move on to our next scenario.

public partial class DoomsDayDevicePresenterScenario {
    [TestFixture]
    public class WhenFireButtonPressed : ScenarioBase {
        [SetUp]
        public void SetUp() {
            CreateDoomsDayDevicePresenterAndDependencies();
            RaiseLoadedEventOnView();
            RaiseFireButtonPressedOnView();
        }

        [Test]
        public void ShouldFireDevice() {
            stubDoomsDayDevice.AssertWasCalled(device => device.Fire());
        }

        [Test]
        public void ShouldDisableFireButton() {
            Assert.That(stubView.FireButtonEnabled, Is.False);
        }
    }
}

Compare this to how one of these tests used to look.

/* plus [SetUp] method code */
[Test]
public void FireButtonShouldFireDoomsDayDevice() {
    RaiseLoadedEventOnView();
    RaiseFireButtonPressedOnView();
    stubDoomsDayDevice.AssertWasCalled(device => device.Fire());
}

Even though this is a trivial example, the new version is much clearer and cleaner. You'll have to take my word for it, but this applies even as you get to more complicated, real code. You tend to push more into the scenario setup (which is exactly what the setup is for) and the tests themselves stay trivial.

Let's look at the final scenario, and at our base class which we have used to keep duplication in check (although not eliminated, as we'll discuss later).

[TestFixture]
public class WhenFiringCompleted : ScenarioBase {
    [SetUp]
    public void SetUp() {
        CreateDoomsDayDevicePresenterAndDependencies();
        RaiseLoadedEventOnView();
        RaiseFireButtonPressedOnView();
        RaiseFiringCompletedOnDevice();
    }

    [Test]
    public void ShouldEnableFireButton() {
        Assert.That(stubView.FireButtonEnabled, Is.True);
    }
}

public class ScenarioBase {
    protected IDoomsDayDeviceView stubView;
    protected IDoomsDayDevice stubDoomsDayDevice;

    protected void CreateDoomsDayDevicePresenterAndDependencies() {
        stubView = MockRepository.GenerateStub<IDoomsDayDeviceView>();
        stubDoomsDayDevice = MockRepository.GenerateStub<IDoomsDayDevice>();
        new DoomsDayDevicePresenter(this.stubView, this.stubDoomsDayDevice);
    }
    protected void RaiseLoadedEventOnView() {
        stubView.Raise(view => view.Loaded += null, this, EventArgs.Empty);
    }
    protected void RaiseFireButtonPressedOnView() {
        stubView.Raise(view => view.FireButtonPressed += null, this, EventArgs.Empty);
    }
    protected void RaiseFiringCompletedOnDevice() {
        stubDoomsDayDevice.Raise(device => device.FiringCompleted += null, this, EventArgs.Empty);
    }
}

Issues with this approach

Duplication in setup methods

All the [SetUp] methods in our scenarios have some duplication -- creating the subject under test and raising basic events. Why don't we factor all this into the base class? There's a few points to consider here. First, do we really want to hide this duplicated setup code? Scott Bellware questions this under the subheading Reuse: Friend or Foe in an article on BDD for CoDe Magazine:

"Specification code is intended to document the behaviors of the system, and this often means leaving duplicated code in-place to support the learnability of the specs... If you do move common context code to a base class, do so with care for how you’re impacting the learning experience of the code"

Having the setup steps repeated to a degree in each scenario (although with the logic behind each step encapsulated as methods in the base class) is great for documenting the scenario, and also helpful with scenario's with fixtures that diverge from the more standard cases (an example of a divergent fixture is one that tests exceptions thrown from a constructor, so we can't have a constructed object setup already).

On the flip side, developers have good reason to be wary of duplication, having Don't Repeat Yourself drummed into them from the moment they are first exposed to inheritance. You can do some really clever things in terms of context base classes. One of the cleverest of these I've seen is JP Boodhoo's developwithpassion.bdd approach, which has the downside of looking completely foreign to people who speak C#, but has the upside of being really nice once you get used to it.

If the duplication bothers you, you can have a general context base class with an existing [SetUp] method that provides hooks like BeforeSetup(), AfterDependenciesCreated() etc. This lets your scenarios hook into whichever parts of the setup chain it needs to and do things like stub out calls. The real trick comes when you want to chain together contexts, which is something JP's approach gives you, and something which you get for free with tools like rspec (using nested blocks).

This is something the purist in me is still questioning, but in practice we've just been leaving the duplication in and have had little to no problems with it, mainly because the duplication is contained to a small, related area, and because the logic itself is neatly encapsulated in a base class.

What goes into the base class?

Anything that can conceivably apply to every scenario. Fields for dependencies, methods to create a subject under test, common operations like raising events etc. You can eliminate some of this by using an automocker, but this can hide design smells like your SUT having too many dependencies.

Tests that apply to multiple scenarios

Sometimes you'll come across a test that should really apply across all the scenarios, an invariant if you will. There's a few approaches for dealing with this. You can put the test in the base class, and it will automatically run against all inheriting scenarios. I hate this approach -- it means you can get multiple failures from one problem, and I don't like the lack of clarity you get with tests being pulled in mysteriously from a base class. You can also create a specific scenario for these things, calling it Always, or if you like the when-convention, WhenEver :).

I really don't like either of these approaches. I've become increasingly suspicious of this actually being a test smell. If you have logic that doesn't depend on a specific scenario, then this could be a cue to extract this into another class to isolate it properly for testing. You can then check the subject under test uses the other class correctly, without worrying about the behaviour changing across multiple scenarios.

We've used all three approaches, with my preference being for isolating the behaviour properly. The WhenEver style approach feels a bit dirty but hasn't caused much grief. The inherited test thing has had mixed results.

Using in conjunction with other organisational methods

Sometimes you end up sprouting classes or writing utilities that don't seem to have a home or fit a particular scenario. In these cases falling back to lumping everything in the one fixture can work just fine. As this post tried to show, it's pretty easy to move to scenario-based testcase classes in future once some scenarios start emerging or when the single fixture starts giving you grief.

Conclusion

Writing tests around scenarios is a way organising your tests which, in my opinion, makes test code easier to write, helps identify common fixtures, and improves the readability and maintainability of tests. Writing testcase classes per scenario ends up breaking down tests by common fixture, but focusing on the scenario makes this breakdown occur more naturally and more maintainably. It is also pretty straight forward to refactor existing tests into this format.

If anyone actually made it this far, I'd love to hear any comments you have on this, both so I can get valuable feedback, and also to lavish you with compliments for actually getting through this epic :). This technique has really dramatically improved how I practice TDD and approach testing, so hopefully it will also help someone else out there.

Dynamic disappointment

2009-06-03T00:35:00.004+10:00

I've been eagerly awaiting .NET 4 and the new dynamic feature in C#, but after taking the beta for a spin I've run in to a major disappointment. Let's take dynamic for a quick spin and see what's got me so devastated.

public class Dynamic : DynamicObject {
    Dictionary<String, object> members = new Dictionary<string, object>();
    public override bool TrySetMember(SetMemberBinder binder, object value) {            
        members[binder.Name] = value;
        return true;
    }
    public override bool TryGetMember(GetMemberBinder binder, out object result) {
        return members.TryGetValue(binder.Name, out result);
    }
}

[TestFixture]
public class Disappointment {
    [Test]
    public void CanCreateAndCallAMethod() {
        dynamic anObject = new Dynamic();
        anObject.AMethod = new Func<int>(() => 1);
        Assert.That(anObject.AMethod(), Is.EqualTo(1));
    }
}

Here we've created a sub-class of DynamicObject, which lets us play in the world of dynamic lookups from C#. We override TrySetMember(...) and TryGetMember(...) to use a dictionary as a backing store for members. Our test assigns a method called AMethod to a dynamic object at run time, then executes it. It passes! Awesome!

If it walks and quacks like a duck, too bad!

Let's declare an ICanAdd interface, as well as a class that uses objects that support the ICanAdd interface to, well, add stuff.

public interface ICanAdd {
    int Add(int a, int b);
}

public class SomethingThatAdds {
    private ICanAdd adder;
    public SomethingThatAdds(ICanAdd adder) {
        this.adder = adder;
    }
    public int FirstNumber { get; set; }
    public int SecondNumber { get; set; }
    public int AddNumbers() {
        return adder.Add(FirstNumber, SecondNumber);
    }
}

We can add this method to our dynamic object so that it supports the same operations as the ICanAdd interface:

[Test]
public void CanCreateADynamicAdder() {
    dynamic adder = new Dynamic();
    adder.Add = new Func<int, int, int>((first, second) => first + second);
    Assert.That(adder.Add(1, 3), Is.EqualTo(4));
}

This works fine, but when we try to combine static and dynamic worlds we run into problems:

[Test]
public void CannotUseDynamicAdderForAnythingUseful() {
    dynamic adder = new Dynamic();
    adder.Add = new Func<int, int, int>((first, second) => first + second);
    var somethingThatCanAdd = new SomethingThatAdds(adder); /* Fails here at runtime */
    somethingThatCanAdd.FirstNumber = 10;
    somethingThatCanAdd.SecondNumber = 20;
    Assert.That(somethingThatCanAdd.AddNumbers(), Is.EqualTo(30));
}

This compiles, but at runtime we get the test failing with the following RuntimeBinderException:

DaveSquared.DynamicDisappointment.Disappointment.CannotUseDynamicAdderForAnythingUseful:
Microsoft.CSharp.RuntimeBinder.RuntimeBinderException : 
The best overloaded method match for 'DaveSquared.DynamicDisappointment.SomethingThatAdds.SomethingThatAdds(DaveSquared.DynamicDisappointment.ICanAdd)' has some invalid arguments
  at CallSite.Target(Closure , CallSite , Type , Object )
  at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
  at DaveSquared.DynamicDisappointment.Disappointment.CannotUseDynamicAdderForAnythingUseful() ...

The exception is fairly clear -- the C# RuntimeBinder is trying to call the SomethingThatAdds(ICanAdd) constructor, but we've given it a dynamic instance instead. Based on my fairly primitive understanding of this stuff, in order to integrate dynamic lookups into the statically typed CLR, dynamic is actually implemented as a static type. So even though we're using dynamic member lookups at runtime, we still need to abide by the type system and pass methods the static types they expect.

If we modify our original SomethingThatAdds class to explicitly accept the dynamic type then our last test passes:

public class SomethingThatAdds {
    private dynamic adder;
    public SomethingThatAdds(dynamic adder) {
        this.adder = adder;
    }
    /* ... snip ... */
}

I'm aware I'm probably expecting too much, but having to explicitly modify our code in order to make this kind of use of the dynamic feature for duck typing is, well, disappointing. It would be great to see something like Jon Skeet's dynamic<T> idea get into the final release so we can get the best of both worlds. :)

Setting up Git difftool on Windows

2009-05-20T10:56:00.000+10:00

After installing Windows 7 I had trouble getting git diff to work properly with diffmerge. In fact, any external tool I tried to define would hang PowerShell once it exited. Unfortunately in the time I had to look at it I couldn't figure out if this was due to a new version of PowerShell with Windows 7, the new version of MSys Git I had installed, or something strange after switching to x64 architecture. What I did have time for was to find a workaround using git difftool, which is a new command added to Git as of version 1.6.3.

The workaround is essential just a tweak of the steps we used previously to get git diff working, so its probably easiest to have a quick skim through that before going through this.

Configuration tweaks

First alteration to the previous approach was to create a difftool wrapper for Diffmerge. I called this git-diff-diffmerge-wrapper.sh and put it in my Git/cmd directory (which is also on my PATH).

#!/bin/sh
"C:/Program Files (x86)/SourceGear/DiffMerge/DiffMerge.exe" "$1" "$2" | cat

Next step was to update .gitconfig to disable the previously added external tool setup for git diff, and configure git difftool in its place.

[diff]
 #external = git-diff-wrapper.sh
 tool = diffmerge

[difftool "diffmerge"]
 cmd = git-diff-diffmerge-wrapper.sh "$LOCAL" "$REMOTE"
 
# ... snipping rest of .gitconfig ... #

I've left the external tool commented out (prefixed by #). This syntax is more in line with the way the we configured the git mergetool last time.

Using `git difftool`

Now whenever we type git diff we will get the standard, textual git difference listing. If we want to use the externally configured tool, we need to type git difftool (followed by the usual range of diff options) and follow the prompts instead. I actually like having the ability to switch between a quick diff and firing up an external tool. With this approach we can also configure multiple diff tools and pick whichever one is our favourite at the moment (or just try out a new diff tool). The command also closely parallels that used to bring up an external tool for merging (git mergetool).

I wish I knew what caused my original issue, but at least I've got my graphical diff tools back for Git. :)

Basic .NET builds using Rake

2009-04-02T00:10:00.005+11:00

I was starting up a new hobby project the other night and thought I'd try using Rake to script my build (instead of pure MSBuild, Nant, or just plain VS). Now Ruby and I generally don't get on too well, so I was really surprised with how easy I found it to setup, and even more surprised with how much I enjoyed it. :)

Prerequisites

Um, Ruby. The installer I used gave me Ruby with Rake included. We'll also need a simple .NET solution. I created one with a structure that looked a bit like this:

DaveSquared.SampleProject

build

rakefile.rb

DaveSquared.SampleProject.Tests
DaveSquared.SampleProject.Web
DaveSquared.SampleProject.sln

tools

NUnit

The SLN file contains two projects, DaveSquared.SampleProject.Tests and .Web. The .Tests project references the .Web project, as well as the NUnit framework buried somewhere in the tools/NUnit directory. Both projects where configured to build to the build/output directory (so .Tests will build to build/output/DaveSquared.SampleProject.Tests).

We can now setup our rakefile.rb, which I've plonked into the build directory. We'll run the build from this directory, so we can specify all our paths relative to this build file.

Basic build and test run

After reading Dave Laribee's post on OMG Rake!, and Mark Guzman's excellent post on Building .NET projects with rake, I then proceeded to ruin all their good work by patching bits and pieces of their posts together and got this:

require 'rake/clean'

DOT_NET_PATH = "#{ENV["SystemRoot"]}\\Microsoft.NET\\Framework\\v3.5"
NUNIT_EXE = "../tools/Nunit/bin/nunit-console.exe"
SOURCE_PATH = "../src"
OUTPUT_PATH = "output"
CONFIG = "Debug"
 
CLEAN.include(OUTPUT_PATH)

task :default => ["clean", "build:all"]
 
namespace :build do
  
  task :all => [:compile, :test]
      
  desc "Build solutions using MSBuild"
  task :compile do
    solutions = FileList["#{SOURCE_PATH}/**/*.sln"]
    solutions.each do |solution|
      sh "#{DOT_NET_PATH}/msbuild.exe /p:Configuration=#{CONFIG} #{solution}"
    end
  end
   
  desc "Runs tests with NUnit"
  task :test => [:compile] do
    tests = FileList["#{OUTPUT_PATH}/**/*.Tests.dll"].exclude(/obj\//)
    sh "#{NUNIT_EXE} #{tests} /nologo /xml=#{OUTPUT_PATH}/TestResults.xml"
  end
  
end

Now the good thing about this is that I don't think you need to know much (any? I know virtually none) Ruby to understand what is going on here, or even to make basic modifications to the tasks (although it might be a struggle if you haven't used build tools like make or nant before). But you can bring the full power of the language to bear when you need it. Let's have a quick step through the main parts of the file.

The first line imports rake/clean, which lets us use CLEAN.include(OUTPUT_PATH) to tidy up for us. We've then got loads of constants to specify various paths: the location of .NET tools like msbuild, and the relative paths to NUnit, our source, and our output. Our :default task is set to run clean, then build:all (the => syntax translates to depends on in make terms, so to run the default task rake will make sure its dependencies are run).

If we drop into the :build namespace, we have :all, :compile and :test tasks defined. To :compile, we use the wonderful FileList class built into rake to get all *.sln files in our source directory, then shell out to msbuild to take care of the hardwork of compiling everything. The :test task relies on convention, by finding all *.Tests.dll files and running them through NUnit. We also make sure that :test won't run until :compile has run by setting :compile as a dependency.

Finally, our :all task compiles and tests the build.

Running our rake build

By dropping into our build directory from the command line, just typing rake will pickup our rakefile.rb and execute our default task, which will clean, compile and test our build. We can also run a task at a time, say rake clean, or rake build:test (the :test task is prefixed by build because of its namespace).

There's obviously tonnes we could do to make this nicer (like using Mark's .NET tasks, and/or removing the hard-coded Debug configuration), but hopefully this gives people a quick way to start getting into rake and ruby for building .NET projects.

Explicitly test what you are trying to test

2009-04-02T00:09:00.000+11:00

Had a problem today that initially took me by surprise. The problem was that this test passed:

[Test]
public void EmptyBlocksShouldBeEqual() {
    var first = new Block();
    var second = new Block();
    Assert.That(first, Is.EqualTo(second));
}

Why was this a problem? Because Block is a reference type and I had not overridden Equals(Object o), so we should fall back to the default Object.Equals(Object o) method which compares object references. The references are clearly different, so this test should fail.

To figure out why this test passes we need two pieces of information. First we need to know how Block is defined:

public class Block : IEnumerable<FrameParameters>  { /* ... snip ... */ }

Second, we need to know that the NUnit EqualConstraint implementation has specific handling for IEnumerable classes. So when I called Assert.That(first, Is.EqualTo(second));, this was just comparing the values returned via enumerating both Block instances. This really wasn't what I wanted -- I was trying to test the Equals() implementation. Here's the corrected test:

[Test]
public void EmptyBlocksShouldBeEqual() {
    var first = new Block();
    var second = new Block();
    Assert.That(first.Equals(second));
}

The moral of the story: make sure you explicitly test what you are trying to test. :)

Too LINQy?

2009-03-19T23:30:00.002+11:00

This post contains a tale of two methods. Well, more precisely, a tale of one method implemented in two different ways -- once using LINQ-based functional-fu, and once using old school procedural code.

Recently I was pairing on a task that required us to keep a running average of multiple sets of samples that came through our app. Unfortunately it was more than likely that some sets of samples would be different lengths (depending on exactly when sampling stopped). In these situations where we were missing samples the requirements were to leave the averages for the missing samples unchanged. When we had extra samples, we should use them as the new average at that position. Here's some tests that hopefully show what we were trying to do:

[Test]
public void ShouldAverageFirstTwoLotsOfSamples() {
    var firstSamples = new float[] { 1, 2, 3 };
    var secondSamples = new float[] { 3, 4, 5 };
    var expectedAverages = new float[] {2, 3, 4};
    _averager.AddSamples(firstSamples);
    _averager.AddSamples(secondSamples);
    Assert.That(_averager.GetAverages(), Is.EqualTo(expectedAverages));
}  

[Test]
public void ShouldAddExtraSamplesToAverages() {
    var firstSamples = new float[] { 1, 2, 3 };
    var secondSamples = new float[] { 3, 4, 5, 2 };
    var expectedAverages = new float[] { 2, 3, 4, 2 };    
    /* ... snip ... */
}

[Test]
public void ShouldHandleShorterNumberOfSamples() {
    var firstSamples = new float[] { 1, 2, 3 };
    var secondSamples = new float[] { 3, 4 };
    var expectedAverages = new float[] { 2, 3, 3};
    /* ... snip ... */
}

A LINQ implementation

After a brief flurry of for looping, we decided to muck around with LINQ to filter and transform the sets of data in a pseudo-functional kind of way.

public class AverageCalculator {
    private float[] _averages = new float[0];
    private uint _numberOfAverages;    

    public void AddSamples(float[] samples) {
        _numberOfAverages++;
        var numberOfNewSamples = samples.Length;
        var numberOfSamplesInLastAverage = _averages.Length;
        var leftOverSamples = samples.Skip(numberOfSamplesInLastAverage);
        var leftOverAverages = _averages.Skip(numberOfNewSamples);

        _averages = _averages
            .Take(numberOfNewSamples)
            .Select(
                (average, sampleIndex) => CalculateNewAverage(average, samples[sampleIndex], _numberOfAverages)
            )
            .Concat(leftOverAverages)
            .Concat(leftOverSamples)
            .ToArray();
    }

    private float CalculateNewAverage(float oldAverage, float newSample, uint totalSamples) {
        return oldAverage + (newSample - oldAverage) / totalSamples;
    }

    public float[] GetAverages() {
        return _averages;
    }
}

Stepping through the logic, we take a maximum of numberOfNewSamples from the running _averages, then calculate the new averages based on each new sample. To handle the possibility of mismatched array sizes, we concatenate any left over items from each array. In reality, one of these arrays of left overs will be empty (depending on which array is larger).

My first thought once the tests went green was "wow that's evil!", but compared with the procedural approach we started with, this one really began to grow on me. It was surprisingly easy to write, but I was concerned about its readability (initially we had the local variables in AddSamples(...) inlined, but we extracted them out to try and make it more readable). We decided to test out the procedural equivalent and see if that was any clearer.

A procedural implementation

public void AddSamples(float[] samples) {
    _numberOfAverages++;

    var largestArray = (samples.Length >= _averages.Length) ? samples : _averages;
    var smallestArray = (samples.Length >= _averages.Length) ? _averages : samples;

    var newAverages = new float[largestArray.Length];
    for (int i = 0; i < newAverages.Length; i++) {
        newAverages[i] = (i < smallestArray.Length) 
                            ? CalculateNewAverage(_averages[i], samples[i], _numberOfAverages) 
                            : largestArray[i];
    }

    _averages = newAverages;
}

The logic used here is to find which array is largest, and to create a new array of that size. We loop through every possible index, calculating the average until all of the smallest array is used, then append the left overs from the largest array. This seems quite neat to me, although I should mention that this is a refactored, sanitised version (as is the LINQ version). The initial implementation was more verbose and the logic less clear, and it somehow managed to take longer to get it to a state where the tests all passed.

Who's right?

Which approach do you like best? It probably comes down to how much imperative vs. functional programming you've done. (Or you hate both versions of the method, in which case please leave a comment with the correct approach. :)). Imperative programming concentrates on telling the computer how to do something, while functional is more about telling the computer what to do. For example, our LINQ version starts with some data and specifies what transformations we want to make to it. Our second version of the code focuses more on the mechanics -- create an array, loop, check the bounds etc.

The second version's focus on implementation makes it fairly easy to mentally trace through how it works, but how clear is the intention behind the implementation? The LINQ version probably takes a bit more effort to understand how it works (especially as the first exposure most people have to programming tends to be to imperative-style control structures like IF, FOR, WHILE and even GOTO), but what it is doing might be a little clearer.

Overall, I kind of prefer the LINQ version for its faint hint of functional elegance, but on the other hand the procedural version is just so darn familiar and comfortable to read for a C#/Java/C person like me. I'd love to hear any thoughts you have on these approaches, and how you are handling the encroachment of functional concepts into our formerly purely-procedural C# language.

Garden Race Pt 3: It's GUI time!

2009-03-15T22:15:00.001+11:00

This post is part of a series exploring the (very) basics of iterative development using the example of a simple Snakes and Ladders-like game. Links to each post in the series will be added to the index page.

After having a think about top-down and bottom-up design, I concluded that delivering complete vertical slices was more important than whether you started at the top or bottom of the slice. As most of the work in previous iterations has been closer to the bottom of our design, it now seems a good time to start writing some tests around the GUI. This work will form the basis of this iteration.

Confession: I had about 3 attempts at this installment of the series over the last year or so, each time having something crop up that stopped me working on it. Some of this post may be biased by previous attempts, although with my poor memory there shouldn't be too much chance of that. :)

Project status and work for iteration 3

Based on the previous two iterations, all we have left from the original list is the "feature squares" (the snakes and ladders style squares):

~~A player can roll the die, and then move that many spaces along the board.~~
A player that ends his or her turn on a "feature square" (a square containing a creature or obstacle), will be moved to the square connected with that feature.
~~There can be 1-4 players, and each player has their turn in sequence.~~
~~A player that reaches the final square wins the game.~~

We'll leave the pending story on hold for now so we can get to the GUI bits. One thing to notice is that none of these stories, strictly speaking, demand a GUI. So let's add one, in consultation with our customers (i.e. firstborn and I):

Each player's position will be displayed on an 8 x 8 grid of squares.

This should give us enough to get rid of the command line demo code and give the customer something closer to a usable product. It will probably be enough to fill the whole iteration as well, as we may have to revisit some of the original stories and make sure we have exposed them all through our GUI (story 1 for example). I've also managed to miss a fairly major part of story 3 -- there is currently no way to choose how many players there are in the game.

I think this indicates a problem with the approach so far. Imagine having to revisit every story after implementing 50 or so due to a change to the front end. One big thing we are missing that could help us avoid this are acceptance tests. If we had those, the relevant ones would fail and we could test drive out our way back to green. It could also be an indication that we have too much logic in the untested demo app. We were aware of this when we wrote the demo app though, and never intended to keep it around long enough for it to become a problem, so manually rechecking our 3 finished stories shouldn't be too big a deal.

Let's start off using WPF for this, as it's shiny and new (well, compared with standard WinForms), and comes standard with our current .NET 3.5 platform. We'd obviously want to do some more research if doing this for real. I've done practically nothing with WPF to date, so I'm looking forward to publicly humiliating myself throughout the remainder of this post. (Why don't my regular readers look surprised? ;))

Where to start?

I'd like to replace our untested demo code with tested, production code that we can use as a foundation for a GUI. We need to make sure the functionality of our original stories are exposed via the GUI, rather than the demo app. The two things that jump out at me is that we need a way for a player to roll a die, and we also need some way to indicate the end of the game. The actual rules of the game are hopefully captured in our Game class, so with a bit of luck we'll only need to verify our UI's interaction with that class. Then to complete our story we'll need to make sure each player's position is displayed on the game board.

I'd love to avoid jumping straight to an MVP-style pattern here, in favour of starting from first principles and refactoring to patterns like that when it becomes painfully obvious we need to. However I have absolutely no idea how to do that test-first, so let's try the standard route of creating a GamePresenter that will mediate between our Game model and our UI. We'll start off with the basics of rolling the die and move on from there.

Rollin', rollin', rollin'

What should happen when a player interacts with the view to roll the die? Well for starters our model class, Game, should probably be updated to reflect the fact the player is having their turn. We don't have an actual GUI button to press, but we know that we can fire off an event when a GUI button is clicked. If we add this event to a view interface, and our real GUI implements that interface, then we'll be able to write automated tests for large number of interactions with our GUI via its interface. Our GUI implementation itself should be fairly basic and concentrate on rendering and widgets rather than application logic (see the Humble Dialog Box [PDF]).

public class GamePresenterSpec {
    [Fact]
    public void Game_should_update_when_roll_die_is_clicked() {
        var fakeGameView = MockRepository.GenerateStub<IGameView>();
        var fakeGame = MockRepository.GenerateMock<IGame>();
        var gamePresenter = new GamePresenter(fakeGameView, fakeGame);

        fakeGameView.Raise(view => view.RollClicked += null, this, EventArgs.Empty);
        fakeGame.AssertWasCalled(game => game.Roll(Arg<int>.Is.Anything));
    }
}

This test isn't really saying much, just that game.Roll(...) should be called with any argument, which is how a player currently has their turn in our model. We need to extract an IGame interface for this, and also create an IGameView and a GamePresenter.

 
public class GamePresenter {
    public GamePresenter(IGameView view, IGame game){}
}

public interface IGameView {
    event EventHandler RollClicked;
}

public interface IGame {
    void Roll(int dieValue);
}

Our test compiles, but fails. We'll fix that now.

public class GamePresenter {
    private readonly IGame _game;
    public GamePresenter(IGameView view, IGame game) {
        _game = game;
        view.RollClicked += view_RollClicked;
    }
    void view_RollClicked(object sender, EventArgs e) {
        _game.Roll(1);
    }
}

Our test now passes, and as I can't see much refactoring to do, let's try the next test. Looking at what we have so far, the most obvious deficiency to me seems to be that we are just rolling 1 in the game. We really need a die roll here (1d6 :)), but that would involve random numbers running around our tests causing havoc. So let's fake a DieRoller that we can use to get known values during tests, and random values during the actual game.

 public class GamePresenterSpec {
    private IGameView fakeGameView;
    private IGame fakeGame;
    private IDieRoller fakeDieRoller;

    private GamePresenter CreateGamePresenterAndDependencies() {
        fakeGameView = MockRepository.GenerateStub<IGameView>();
        fakeGame = MockRepository.GenerateMock<IGame>();
        fakeDieRoller = MockRepository.GenerateStub<IDieRoller>();
        return new GamePresenter(fakeGameView, fakeGame, fakeDieRoller);            
    }
    /* ... snip ... */
    [Fact]
    public void Game_should_roll_value_from_die_when_roll_die_is_clicked() {
        CreateGamePresenterAndDependencies();
        int dieFace = 3;
        fakeDieRoller.Stub(die => die.Roll()).Return(dieFace);

        RaiseRollClickedEventOnView();
        fakeGame.AssertWasCalled(game => game.Roll(dieFace));
    }

    private void RaiseRollClickedEventOnView() {
        fakeGameView.Raise(view => view.RollClicked += null, this, EventArgs.Empty);
    }
}

The new test stubs out a known value for IDieRoller.Roll(), then makes sure that will get passed to our Game. I've also shown that we've extracted the common fixture setup code into a CreateGamePresenterAndDependencies() method, although we'd normally do this refactoring after all the tests get to green (unfortunately this stuff is surprisingly difficult to get into blog-form, so please excuse me taking some licence with presentation).

public class GamePresenter {
    private readonly IGame game;
    private readonly IDieRoller roller;

    public GamePresenter(IGameView view, IGame game, IDieRoller roller) {
        this.game = game;
        this.roller = roller;
        view.RollClicked += view_RollClicked;
     }

    void view_RollClicked(object sender, EventArgs e) {
        game.Roll(roller.Roll());
    }
}

public interface IDieRoller {
    int Roll();
}

And we're back at green. What else can we look at? Well we should probably display the result of the roll to the player. Like our view.RollClicked event, we'll just make our view interface have a method for setting the result of a die roll (say, ShowRollResult(dieFace)), and we'll let our actual GUI implementation worry about translating this message to the display.

[Fact]
public void View_should_show_result_of_roll() {
    CreateGamePresenterAndDependencies();
    int dieFace = 2;
    fakeDieRoller.Stub(die => die.Roll()).Return(dieFace);
    RaiseRollClickedEventOnView();
    fakeGameView.AssertWasCalled(view => view.ShowRollResult(dieFace));
}

public class GamePresenter {
    private readonly IGameView view;
    /* ... snip ... */
    void view_RollClicked(object sender, EventArgs e) {
       var dieValue = roller.Roll();
       game.Roll(dieValue);
       view.ShowRollResult(dieValue);
    }
}

Whose turn is it anyway?

Tests pass, and can't see any refactoring to do. It is probably important to show whose turn it is, so let's try that now. First up, we need to show the current player when the game is first started.

[Fact]
public void View_should_show_current_player_when_game_is_created() {
    CreateGamePresenterAndDependencies();
    var currentPlayer = 1;
    fakeGame.Stub(game => game.CurrentPlayer).Return(currentPlayer);
    fakeGameView.AssertWasCalled(view => view.SetCurrentPlayer(currentPlayer));

}

Oops, this won't work. We are using CreateGamePresenterAndDependencies() to create everything in one step, but then we go on to stub out the game.CurrentPlayer call. Let's separate the dependency creation from the creation of the subject under test.

[Fact]
public void View_should_show_current_player_when_game_is_created() {
    CreateGameDependencies();
    var currentPlayer = 1;
    fakeGame.Stub(game => game.CurrentPlayer).Return(currentPlayer);
    new GamePresenter(fakeGameView, fakeGame, fakeDieRoller);
    fakeGameView.AssertWasCalled(view => view.SetCurrentPlayer(currentPlayer));
}

Note: this kind of mucking around with the fixture is a drawback of using a fixture-per-class style of test organisation. This seems to be how most people start TDD (myself included), but I think using a fixture-per-scenario approach (more of a BDD style) is easier to use and probably to learn from. I'm using a more BDD-like approach for my real code now, and am finding it generally makes TDD much easier. I still haven't got it right yet though, so both for that reason and for consistency I'll stick with fixture-per-class for this post.

To get this passing we'll need to pull up Game.CurrentPlayer to the IGame interface, then update the GamePresenter constructor to pass this information to the view.

public GamePresenter(IGameView view, IGame game, IDieRoller roller) {
    this.view = view;
    this.game = game;
    this.roller = roller;
    view.RollClicked += view_RollClicked;
    view.SetCurrentPlayer(game.CurrentPlayer);
}

That handles the start of the game, but we also need to change whose turn it is after each roll.

[Fact]
public void View_should_show_current_player_after_a_roll() {
    CreateGamePresenterAndDependencies();
    var player = 2;
    fakeGame.Stub(game => game.CurrentPlayer).Return(player);
    RaiseRollClickedEventOnView();
    fakeGameView.AssertWasCalled(view => view.SetCurrentPlayer(player));
}

/* In GamePresenter: */
void view_RollClicked(object sender, EventArgs e) {
    var dieValue = roller.Roll();
    game.Roll(dieValue);
    view.ShowRollResult(dieValue);
    view.SetCurrentPlayer(game.CurrentPlayer);
}

Ugh: Looking back through my notes while I'm typing this up, I have something to the effect of "Seems ugly. Using WPF, shouldn't I be binding to the ViewModel/PresentationModel?". This is fairly important -- I'm going to blatantly end up misusing WPF in this case because I'm not taking advantage of any of the nice databinding features it has. Let's press on though, if for no reason other than to point at the author and laugh at his incompetence. Maybe we can salvage what we have later on.

Where am I?

Ostensibly the story we are working on is to display each player's position on the grid. It should not be too hard to update each player's position after they take their turn. Because I haven't done enough of a spike to see how our view should work, let's just assume we have a MovePlayerMarker(...) method on the view that will handle any animation or display stuff we need.

[Fact]
public void Should_update_players_position_after_roll() {
    CreateGamePresenterAndDependencies();
    var player = 1;
    var newSquare = 10;
    var oldSquare = 5;
    fakeGame.Stub(game => game.CurrentPlayer).Return(player);
    fakeGame.Stub(game => game.GetSquareFor(player)).Return(oldSquare);
    fakeGame.Stub(game => game.GetSquareFor(player)).Return(newSquare);
    RaiseRollClickedEventOnView();

    fakeGameView.AssertWasCalled(view => view.MovePlayerMarker(player, oldSquare, newSquare));
}

/* In GamePresenter: */
void view_RollClicked(object sender, EventArgs e) {
    var dieValue = roller.Roll();
    var player = game.CurrentPlayer;
    var startingSquare = game.GetSquareFor(player);
    game.Roll(dieValue);
    view.ShowRollResult(dieValue);
    view.SetCurrentPlayer(player);
    view.MovePlayerMarker(player, startingSquare, game.GetSquareFor(player));
}

We are really starting to run into some of the limitations of our Game class now. As soon as a player rolls the die in the game, the positions and current player changed, so we need to save this information prior to calling game.Roll(...). This may indicate we may have an overly intimate implementation. We need to know all kinds of stuff about the Game implementation to use it, which is making our view_RollClicked(...) code fairly ugly as it steps through the procedure of running the game. Maybe we should instead expose a list of player positions that we could bind to instead?

It looks like we are due for some refactoring, but I'm not really sure how to proceed with that. Instead of letting that hold us up as we worry about all the potential solutions we could pick, let's put that off and whack up a quick view implementation and see if that helps at all.

This time I'm playing to win!

Before we make that final step to the GUI implementation we still need to handle one more case from our original console app -- winning the game. Here's two tests and an implementation that passes them both (although written one at a time, of course!).

[Fact]
public void Should_show_winner_when_game_is_finished() {
    CreateGamePresenterAndDependencies();
    int player = 3;
    fakeGame.Stub(game => game.CurrentPlayer).Return(player);
    fakeGame.Stub(game => game.IsFinished).Return(true);
    RaiseRollClickedEventOnView();
    fakeGameView.AssertWasCalled(view => view.ShowWinner(player));
}

[Fact]
public void Should_disable_die_roll_when_game_is_finished() {
    CreateGamePresenterAndDependencies();
    fakeGame.Stub(game => game.IsFinished).Return(true);
    RaiseRollClickedEventOnView();
    fakeGameView.AssertWasCalled(view => view.DisableDieRolls());
}

/* In GamePresenter: */
void view_RollClicked(object sender, EventArgs e) {
    var dieValue = roller.Roll();
    var player = game.CurrentPlayer;
    var startingSquare = game.GetSquareFor(player);
    game.Roll(dieValue);
    view.ShowRollResult(dieValue);
    view.SetCurrentPlayer(player);
    view.MovePlayerMarker(player, startingSquare, game.GetSquareFor(player));
    if (game.IsFinished) {
        view.DisableDieRolls();
        view.ShowWinner(player);
    }
}

The worst, most blatant misuse of WPF in history!!!1!

I'm not proud of what you are about to see. In fact, I'm rarely proud of any of the crud I write on this blog, but if my normal stuff is a 2 out of 10, this is about a -30 * 10¹². My local check-in comment for this stuff is "Embarrassingly bad GUI using WPF controls", which is pretty accurate. I'm using WPF controls, but saying this is WPF is like wrapping a 1000 line main method in a class declaration and calling it OO. But I did promise a GUI of sorts, so let's try and get something graphical working.

Don't do this! In case you missed my subtle hints throughout this post, don't repeat what you are about to see. It would be pure evil if it weren't for its lack of competence. Don't bother donning the goggles, they'll do nothing.

First, I've created a new DaveSquared.GardenRace.Gui WPF project to house this hideous monstrosity. I've created a new WPF form called GardenRaceView. Here's the XAML.

<Window x:Class="DaveSquared.GardenRace.Gui.GardenRaceView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="GardenRaceView" Height="526" Width="716">
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="528*" />
            <ColumnDefinition Width="166*" />
        </Grid.ColumnDefinitions>
        <UniformGrid Name="gameBoard" Rows="8" Columns="8" />
        <Label Grid.Column="1" Height="28" Margin="0,12,46,0" Name="currentPlayer" VerticalAlignment="Top">currentPlayer</Label>
        <Button Grid.Column="1" Height="23" Margin="46,46,46,0" Name="rollDieButton" VerticalAlignment="Top" Click="rollDieButton_Click">Roll</Button>
        <Label Grid.Column="1" Height="28" Margin="0,86,46,0" Name="rollResult" VerticalAlignment="Top">rollResult</Label>
        <Ellipse Visibility="Hidden" Name="player1Marker" Stroke="Black" Height="30" Margin="5, 0, 0, 0" HorizontalAlignment="Left" VerticalAlignment="Top" Fill="Red" Width="30" />
        <Ellipse Visibility="Hidden" Height="30" HorizontalAlignment="Left" Name="player2Marker" Stroke="Black" Fill="Blue" VerticalAlignment="Top" Width="30" />
    </Grid>
</Window>

This gives us two columns to work with: The left hand column to hold the board, and the right hand column for status and game controls. Let's wire this thing up. Here is the xaml.cs file. This was originally wired up piece by piece, manually testing in between (we don't have automated tests for the view remember).

public partial class GardenRaceView : Window, IGameView {
    public GardenRaceView() {
        InitializeComponent();
        FillSquares();
        MoveToStartingPositions();
        var gameModel = new Game(64, 2);
        new GamePresenter(this, gameModel, new DieRoller());
    }

    private void MoveToStartingPositions() {
        MovePlayerMarker(1, 0, 0);
        MovePlayerMarker(2, 0, 0);
    }

    private void FillSquares() {                        
        for (var squareNumber=1; squareNumber <= 64; squareNumber++) {
            var square = new StackPanel();
            var squareLabel = new Label();                
            squareLabel.Content = squareNumber;
            square.Children.Add(squareLabel);
            gameBoard.Children.Add(square);
        }
    }

    public event EventHandler RollClicked;

    private void OnRollClicked() {
        EventHandler rollClickedHandler = RollClicked;
        if (rollClickedHandler != null) rollClickedHandler(this, EventArgs.Empty);
    }

    public void ShowRollResult(int dieFace) {
        rollResult.Content = "You rolled a " + dieFace;
    }

    public void SetCurrentPlayer(int player) {
        currentPlayer.Content = "Player " + player + "'s turn.";
    }

    public void MovePlayerMarker(int player, int fromSquare, int toSquare) {            
        var markerForPlayer = GetMarkerForPlayer(player);
        markerForPlayer.Visibility = Visibility.Visible;
        
        var containerForMarker = (Panel) markerForPlayer.Parent;
        containerForMarker.Children.Remove(markerForPlayer);

        if (toSquare >= gameBoard.Children.Count) toSquare = gameBoard.Children.Count-1;
        var newSquare = (StackPanel) gameBoard.Children[toSquare];
        newSquare.Children.Add(markerForPlayer);            
    }

    private Shape GetMarkerForPlayer(int player) {
        if (player == 1) { return player1Marker; }
        if (player == 2) { return player2Marker; }
        throw new ArgumentOutOfRangeException();
    }

    public void ShowWinner(int winningPlayer) {
        MessageBox.Show("Player " + winningPlayer + " wins! Nice work!");
    }

    public void DisableDieRolls() {
        rollDieButton.IsEnabled = false;
    }

    private void rollDieButton_Click(object sender, RoutedEventArgs e) {
        OnRollClicked();
    }
}

If you haven't been blinded yet, the first thing you'll have seen is that we make our form implement our IGameView. The majority of these implementations are trivial: ShowRollResult(...), SetCurrentPlayer(...), ShowWinner(...), DisableDieRolls(), and firing the RollClicked event. The MovePlayerMarker(...) is fairly hideous, but it is pretty much all view-specific logic (except the highlighted code that does bound checking on the player's positions).

There is also some code in the constructor to fill our UniformGrid (in the incorrect order mind you), and then the code to instantiate our presenter and model code. I don't really see a pressing need for an IoC container here yet, do you? :)

The only other implementation is the pseudo-random DieRoller which we pass through to our presenter:

internal class DieRoller : IDieRoller {
    Random random = new Random();
    public int Roll() {
        return random.Next(1, 6);
    }
}

Somewhat surprisingly, this manages to actually work (er, well, somewhat work :)).

On what poor, pitiful, defenseless customers has my monstrosity been unleashed?

So what have we done? Besides unsubscribing from Dave's blog, we also managed to test drive a presenter and unleash a hideous GUI on our unsuspecting customers. We've done a very rough job on this story (my fault, not yours), but we are now displaying players' positions on a grid. The grid is not in the correct order for a snakes and ladders-style game (it is meant to snake around, starting at the bottom of the board and winding its way up to the top), but we can refine this later. We've also replaced our untested, console-only demo app with a tested, hideous bastardisation of WPF.

We've also found lots of new tasks to do. First, learn WPF. Next, refactor this to have a more useful Game class, and maybe change the presenter into more of a presentation model approach so we can use some WPF goodness. We also need to do something about our incomplete story about being able to play with 1 - 4 players -- at present we have 2 players hard coded in. And we also should put in some snake and/or ladder-like squares.

Despite the obvious problems with the current code, I'd like to try and salvage some small glimmer of positivity from this post. We managed to test drive a whole host of GUI-specific functionality, before we even had a forms project. We managed to hook in a thin view on top of that foundation that, despite being ugly, just worked. (Really it did! If I was going to start lieing to you it would have been in an attempt to hide my incompetence during the rest of the post, not for something trivial like this ;)). And last but not least -- um, no, actually they're the only positives I can think of. :)

I hope you can get some value from this post, even if its just a laugh or two at my expense. :) I'd love to hear your thoughts as to whether what we've got here is salvageable, and if so then how you would start evolving it in the right direction. In the meantime, I'm off to read up on WPF.

Testing a class for making asynchronous calls

2009-02-27T22:31:00.004+11:00

In my last post I looked at doing all kinds of evil things to get some legacy code under test. The code in question launched a new thread to do some work, and I ended up wrapping this asynchronous call in a ThreadDispatcher class for testing.

public class ThreadDispatcher {
  public AsyncCall Dispach(Action function) {
    var thread = new Thread(() => function());
    thread.Start();
    return new AsyncCall(thread);
  }
}

public class AsyncCall {
  private readonly Thread _thread;
  public AsyncCall(Thread thread) { _thread = thread; }
  public void WaitUntilCallFinishes() { _thread.Join(); }
}

I could then test the dispatcher like this:

[Test]
public void RunsFunctionFromDifferentThread() {
  var dispatcher = new ThreadDispatcher();
  int callingThreadId = Thread.CurrentThread.ManagedThreadId;
  int dispatchedThreadId = callingThreadId;
  var asyncCall = dispatcher.Dispach(() => dispatchedThreadId = Thread.CurrentThread.ManagedThreadId);
  asyncCall.WaitUntilCallFinishes();
  Assert.That(dispatchedThreadId, Is.Not.EqualTo(callingThreadId));
}

There's (at least) two problems with this. First, the return value of this function is a complete contrivance for the sake of testability (so our tests can call asyncCall.WaitUntilCallFinishes() before checking any assertions). This isn't always a bad thing, but in this case we are adding functionality and complexity that the production code does not need (the fact that the return value is always ignored in production code doesn't seem very reassuring). The second problem is that if we want to use the ThreadPool to run the work in the background then we don't get a reference to a Thread, and therefore can't wait on it.

A neater approach

This week I was faced with an actual need to do something like this (the previous implementation was an exercise stemming from a discussion with a mate). I ended up using similar TDD steps to come up with what I feel is a nicer way of testing a fire-and-forget asynchronous call. The implementation itself is trivial, and removes all traces of waiting on/joining threads:

public class AsynchronousDispatcher {
    public void Execute(Action action) {
        ThreadPool.QueueUserWorkItem(state => action());
    }
}

The fun part is the tests. Seeing as we've removed the concept of waiting from our implementation, this has to be handled from our tests instead. Which is fine, because the tests are the only place we need this functionality.

[Test]
public void ShouldExecuteAction() {
    var wasRun = false;
    DispatchToThreadAndWaitUntilDone(() => wasRun = true);
    Assert.That(wasRun, "Expected action to execute");
}

[Test]
public void ShouldExecuteActionOnDifferentThread() {
    var currentThreadID = Thread.CurrentThread.ManagedThreadId;
    var dispatchedThreadID = currentThreadID;

    DispatchToThreadAndWaitUntilDone(() => dispatchedThreadID = Thread.CurrentThread.ManagedThreadId);
    Assert.That(dispatchedThreadID, Is.Not.EqualTo(currentThreadID));
}

private void DispatchToThreadAndWaitUntilDone(Action action) {
    var resetEvent = new AutoResetEvent(false);
    var dispatcher = new AsynchronousDispatcher();
    dispatcher.Execute(() =>
                           {
                               action();
                               resetEvent.Set();
                           });
    resetEvent.WaitOne();
}

You'll see that the tests themselves are almost identical to the ones from last time, as most of the hard work is done in the DispatchToThreadAndWaitUntilDone(Action action) function. This uses an AutoResetEvent to handle synchronisation, and signals (resetEvent.Set()) as part of the work being done on our new thread. While the new thread is busy doing its asynchronous thang, the thread running our test uses WaitOne() to patiently sit around until it gets signaled that the asynchronous thread is done. We can then check that the results of the asynchronous operation matched what we expected, which for these tests is just that the code was run and that it used a different thread to run it.

So now we've got a trivial and tested implementation we can use to make asynchronous calls. If we extract an interface (or make Execute(...) virtual) we can easily mock this or replace it with a synchronous implementation to test classes that need to use AsynchronousDispatcher.

Apologies if this is all a bit simplistic, but I thought the tests looked kinda neat so I thought I'd share. Feel free to rip gigantic holes in it all. :)

Testing legacy code when simple threading's involved

2009-02-10T00:29:00.027+11:00

A good friend and "former colleague in (an) archaic dev team" (his words :)) recently sent me a problem he was having testing some code he inherited. The code seemed to work during manual testing, but threw exceptions when being tested using NUnit under certain conditions. Let's look at a drastically modified example of the code:

[TestFixture]
public class BigImportantClassFixture {
  [Test]
  public void CanGetKnownEmployee() {
    var existingEmployeeId = Guid.Empty
    var importantClass = new BigImportantClass();
    var employee = importantClass.GetEmployee(existingEmployeeId);
    Assert.That(employee.Name, Is.EqualTo("Bilbo"));
  }
}

public class BigImportantClass {
  public Employee GetEmployee(Guid employeeID) {
    Employee employee = EmployeeRepository.GetEmployeeByID(employeeID);
    Logging.AsyncLog("Called GetEmployeeByID");
    return employee;
  }
}

public static class Logging {
  public static void AsyncLog(string message) {            
    var thread = new Thread(Log);
    thread.Start(message);
  }

  private static void Log(object message) {
    //Write line to log. This op may take some time
    Thread.Sleep(1000);
    Console.WriteLine(message);
  }
}

Can you guess the exception that cropped up? The unit test runner tears down the app domain it uses to run the fixtures when it is finished. Because the code spawns a new thread, this means that if that thread is still running it gets aborted as the app domain exits, so we get a ThreadAbortException. So how can we get this under test?

Questioning the approach

I think it would be remiss of us not to spend some time considering why we are using this approach. Is GetEmployee() called a lot and so needs to be fast? Will the added burden of spinning up another thread per call help, or will it hinder overall performance due to the increased load on the system? Would we be better off with a synchronous call? Do we even need logging here? Have we looked at using AOP for logging? Can libraries like log4net handle asynchronous logging for us? Or should we implement our own queue and have that serviced by threads that can work on processing the logs in batches? Should we be using background threads from the ThreadPool? Should we look at message queuing? Are static methods and opaque dependencies like this a work of pure evil? And if you were a tree, what tree would you be?

These are all good questions to ask and something my mate is looking into (I think he's leaning toward the larch). For the rest of this post however, I'd like to concentrate on how we could get this code under test. The code currently seems to work, but we don't have automated tests covering it, so we'll try and keep code changes small to give us confidence we aren't breaking anything during the process. This means we'll try and avoid changes ripping out the dependencies and using constructor injection. Once it's under test, we can worry about making it purdy and move on to more complex refactorings, and maybe even change the whole logging implementation once we decide which approach to use.

Isolating the logging behaviour in `GetEmployee()`

Our GetEmployee method does two things: looks up an Employee and does some logging. We already have the beginning of a test for the employee lookup part, but the coupling to the logging functionality is causing some problems. It is also untested. Let's write a test that isolates the behaviour.

[Test]
public void GetEmployeeCallIsLogged() {
  var mockLogger = MockRepository.GenerateMock<ILogger>();
  Logging.SetLogger(mockLogger);

  var importantClass = new BigImportantClass();
  importantClass.GetEmployee(Guid.Empty);

  mockLogger.AssertWasCalled(mock => mock.AsyncLog(Arg<String>.Is.Anything));
}

Normally I'd look at constructor injection for this sort of thing, but we're aiming for minimal modifications to the original code. Logging is also a bit of a special case — you potentially need it everywhere and so you may not want to explicitly put ILogger objects into every single object you have.

To pass this test, we'll need to extract an ILogger interface from our static Logger class, and change the implementation to use a Singleton approach (so we can override the behaviour by changing the instance).

public interface ILogger {
  void AsyncLog(string message);
}

public class Logging : ILogger {
  private static ILogger instance = new Logging();
  public static void SetLogger(ILogger logger) { instance = logger; }

  public static void AsyncLog(string message) {            
    instance.AsyncLog(message);
  }

  private static void Log(object message) {
    //Write line to log. This op may take some time
    Thread.Sleep(1000);
    Console.WriteLine(message);
  }

  void ILogger.AsyncLog(string message) {
    var thread = new Thread(Log);
    thread.Start(message);
  }
}

This passes our test. Notice we've made virtually no changes to the pre-existing code and only a few minor additions. We've added a singleton instance and a trivial SetLogger() method, and moved the code previously in the static AsyncLog() method into the ILogger.AsyncLog() instance method, with the static methods delegating to the instance one. We haven't had to change the GetEmployee() method at all. Hopefully this means we haven't broken anything. A quick manual test verifies that everything is working as before.

I'm a bit worried that we might replace the singleton instance with something evil during one test and inadvertently cause another test to break, but I guess that's a price of using singletons. At this point we just want to get the code under test before we go trying to make it all purdy. On the positive side, we can now test the employee lookup functionality independently of the logging, including testing that GetEmployee() invokes the logging call as required.

An integration test for logging

We've isolated our logging behaviour and tested it is called correctly from GetEmployee(), which means we can now write a test to make sure our logging works when it is called.

[TestFixture]
public class LoggingFixture {
  [Test]
  public void AsyncLogShouldDoFunkyLoggingStuff() {
    ILogger logging = new Logging();
    logging.AsyncLog("some message");
    Thread.Sleep(2000);
    //AssertDesiredSideEffectOccurred();
  }
}

Because of our previous efforts we can work directly with a Logging instance, rather than through the static methods. We still have a problem though. We want to check that whatever effect AsyncLog() has occurred properly, but because it is called asynchronously we have to put in a hacky Thread.Sleep() to make sure it is done. There are a few problems with this approach. Firstly, how do we know 2000 ms is enough? We might have our test intermittently breaking, which is a huge no-no. Secondly, it will make our tests run slow.

Isolating our threading problem

We'd really like the option of using Thread.Join() or similar so our test can wait on the asynchronous operation to finish. But we currently don't have any way to access the threading part of the operation.

One way to solve this problem is to implement the Asynchronous Programming Model. This lets the operation to be called asynchronously and waited on using polling/spin loop, call back or wait handle. Unfortunately it also looks like quite a lot of work, and a large amount of change to make without tests.

Another possible solution is to isolate the threading behaviour from the logging operation, just as we did for separating the employee lookup from the logging. Let's try that — we'll write a class that specialises in running a function in a new thread.

[TestFixture]
public class ThreadDispatcherFixture {
  [Test]
  public void CanRunFunctionCall() {
    var dispatcher = new ThreadDispatcher();
    bool wasRun = false;
    dispatcher.Dispach(() => wasRun = true);
    Assert.That(wasRun);
  }
}

public class ThreadDispatcher {
  public void Dispach(Action function) {
    function();
  }
}

This passes. Let's expand our test fixture, and try a naive implementation:

[Test]
public void RunsFunctionFromDifferentThread() {
  var dispatcher = new ThreadDispatcher();
  int callingThreadId = Thread.CurrentThread.ManagedThreadId;
  int dispatchedThreadId = -1;
  dispatcher.Dispach(() => dispatchedThreadId = Thread.CurrentThread.ManagedThreadId);
  Assert.That(dispatchedThreadId, Is.Not.EqualTo(callingThreadId));
}
//...
public class ThreadDispatcher {
  public void Dispach(Action function) {
    var thread = new Thread(() => function());
    thread.Start();
  }
}

This passes the new RunsFunctionFromDifferentThread() test, but luckily fails the original CanRunFuctionCall() test when run on my machine. I say luckily because it is timing dependent — the thread has not completed by the time the Assert.That(wasRun) executes. If you slip in a Thread.Sleep(...) for a few milliseconds you'll see both tests pass as the async thread starts to win our race condition.

This is a really good illustration that test coverage does not equal correctness, nor is it an excuse to avoid thinking :). Given we've thought about the problem though, TDD can help lead us to a solution. We need to make sure our async thread has run before we call our assert, so let's ammend our tests to show this:

[Test]
public void CanRunFunctionCall() {
  var dispatcher = new ThreadDispatcher();
  bool wasRun = false;            
  var dispatchedThread = dispatcher.Dispach(() => wasRun = true);
  dispatchedThread.Join();
  Assert.That(wasRun);
}
[Test]
public void RunsFunctionFromDifferentThread() {
  var dispatcher = new ThreadDispatcher();
  int callingThreadId = Thread.CurrentThread.ManagedThreadId;
  int dispatchedThreadId = callingThreadId;
  var dispatchedThread = dispatcher.Dispach(() => dispatchedThreadId = Thread.CurrentThread.ManagedThreadId);
  dispatchedThread.Join();
  Assert.That(dispatchedThreadId, Is.Not.EqualTo(callingThreadId));
}

And a reliably passing implementation (I hope):

public Thread Dispach(Action function) {
  var thread = new Thread(() => function());
  thread.Start();
  return thread;
}

It may not be a good idea to pass a reference to the Thread back, so it might be neater to wrap the Join() functionality in a new class (with tests updated accordingly).

public class ThreadDispatcher {
  public AsyncCall Dispach(Action function) {
    var thread = new Thread(() => function());
    thread.Start();
    return new AsyncCall(thread);
  }
}

public class AsyncCall {
  private readonly Thread _thread;
  public AsyncCall(Thread thread) { _thread = thread; }
  public void WaitUntilCallFinishes() { _thread.Join(); }
}

This is all new code, so we shouldn't have broken anything that was working in our original implementation.

Bringing logging and threading back together

Now we've separated logging and threading, we need to bring them back together so this thing actually works as required. Let's jump into our LoggingFixture:

[TestFixture]
public class LoggingFixture {
  [Test]
  public void AsyncLogShouldDoFunkyLoggingStuff() {
    ILogger logging = new Logging(new ThreadDispatcher());
    logging.AsyncLog("some message");
    Thread.Sleep(2000);
    //AssertDesiredSideEffectOccurred();
  }

  [Test]
  public void AsyncLogShouldUseThreadDispatcher() {
    var dispatcher = MockRepository.GenerateMock<ThreadDispatcher>();
    ILogger logging = new Logging(dispatcher);
    logging.AsyncLog("some message");
    dispatcher.AssertWasCalled(x => x.Dispach(null), options => options.IgnoreArguments());
  }
}

public class Logging : ILogger {
  private readonly ThreadDispatcher dispatcher;
  private static ILogger instance = new Logging(new ThreadDispatcher());

  public Logging(ThreadDispatcher dispatcher) { this.dispatcher = dispatcher; }

  public static void SetLogger(ILogger logger) { instance = logger; }

  public static void AsyncLog(string message) {            
    instance.AsyncLog(message);
  }

  private static void Log(object message) {
    //Write line to log. This op may take some time
    Thread.Sleep(1000);
    Console.WriteLine(message);
  }

  void ILogger.AsyncLog(string message) {
    dispatcher.Dispach(() => Log(message));
  }
}

This has probably been the most radical change to our code. We've changed the implementation of AsyncLog to delegate the threading to our new ThreadDispatcher. We've also added some dependency injection, using the Logging constructor to pass in our ThreadDispatcher. Everything is green. Even better, we can now update the original AsyncLogShouldDoFunkyLoggingStuff() and test the logging behaviour in isolation.

[TestFixture]
public class LoggingFixture {
  private class FakeThreadDispatcher : ThreadDispatcher {
    public override AsyncCall Dispach(Action function) {
      function();
      return new AsyncCall(null);
    }
  }
  [Test]
  public void AsyncLogShouldDoFunkyLoggingStuff() {
    ILogger logging = new Logging(new FakeThreadDispatcher());
    logging.AsyncLog("some message");
    //No more Thread.Sleep(...) here. Our FakeThreadDispatcher will do a synchronous call.
    //AssertDesiredSideEffectOccurred();
  }
  //...
}

You could also do some fancy mockFu for this, but in this case I think it's easier to hand code a FakeThreadDispatcher (if changes to the base class cascade down to our fake and it starts getting painful we can switch a generated mock or stub).

Conclusion

Our Logging implementation only calls Console.WriteLine(), so for our AssertDesiredSideEffectOccurred() we would need to fake that out. We won't go that far down the rabbit hole though, as the real logging implementation would be probably do all kinds of exciting things that we could test. The point is that we can now test the logging in isolation from our threading. Our threading code is also tested, and we can test our original employee look up too (by setting a stub ILogger when testing BigImportantClass).

Best of all, the only really changes of any consequence we made to our original code is implementing a singleton Logging instance and extracting the thread launching code to a new class. So, from a unit testing point of view, we have gained a lot for very little risk.

This was a very simple bunch of refactorings to perform. I hope that came across during the post, but sometimes these things don't translate well to post format. If that's the case then try picking up the code from the start of this post and go through the process of getting it under test.

As always feel free to pick holes in this post and let me know via comment or email. Hope this helps!

Git-aware PowerShell prompt

2009-02-04T23:54:00.010+11:00

Today a colleague sent around an interesting link on how to put your git status in your bash prompt. I thought I'd spend a few minutes trying to get a similar effect in PowerShell (v2 CTP3). It's not particularly useful, but I found it an interesting exercise. Here's what I came up with, saved in GitAwarePrompt.ps1. Disclaimer: I know nothing about PowerShell so use anything from this post at your own risk. :)

function Get-GitBranchNameWithStatusIndicator {
  $statusOutput = Invoke-Expression 'git status 2>$null'  #1
  if (!$statusOutput) { return } #2
  $branch = $statusOutput[0] #3
  if ($branch -eq "# Not currently on any branch.") {
    $branch = "No branch"
  } else {
    $branch =  $branch.SubString("# On branch ".Length) 
  }
  $statusSummary = $statusOutput[-1] #4
  if ($statusSummary -eq "nothing to commit (working directory clean)") { #5
    $statusIndicator = "" 
  } else {
    $statusIndicator = "*"
  }
  return $branch + $statusIndicator
}

function prompt { #6
  $gitStatus = Get-GitBranchNameWithStatusIndicator
  Write-Host ("PS " + $(get-location)) -nonewline
  if ($gitStatus) {
    Write-Host (" [" + $gitStatus +"]") -nonewline -foregroundcolor Gray
  }
  Write-Host (">") -nonewline
  return " "
}

I've put some numbered comments on a couple of lines so we can go through the main parts of the script, or you can skip to the next heading if you just want to try out the script.

Line #1 uses the Invoke-Expression commandlet to run the git status command and store the output in the local $statusOutput variable. We are using 2>$null to drop any output written to standard error, otherwise whenever we try and write a prompt in a non-git directory we'll get a git error message appearing. You'll also notice we have the git status 2>$null command surrounded by single quotes ('), rather than double quotes ("). The reason is that PowerShell automatically performs variable substitution within double quoted strings. So if we used double quotes the $null would be replaced by with nothing (it's current value), which will cause us no end of problems (go on, ask me how I know! :)).

If the git status command errors out (say, if the current directory is not in a git repo), then $gitStatus will be null. Line #2 checks for this and returns void if $statusOutput is undefined. Otherwise $statusOutput will an array of objects, with an item for each line of the command output. Line #3 grabs the first line of output, which contains a string which contains our branch name, and stores it in a variable. The if/else that follow checks first to make sure we are actually on a branch, and parses the branch name from the line.

Line #4 was a nice surprise for me -- PowerShell supports wrapped array indexing! Using an index of -1 grabs the last item in the array. Very pythonesque :). Line #5 then compares this with the output git status gives when there are no changes, and the rest of the if/else block sets the $statusIndicator based on this result. (No built in ternary operator apparently.)

Finally, line #6 defines a prompt function, which PowerShell uses to write it's prompt.

Using the script

If we just run this script from within PowerShell it will do absolutely nothing. The reason is because any functions or variables defined will be cleaned up when the script exits. To change the scope and affect the current environment we need to dot-source the script, like this (depending on where you saved the script):

PS > . $HOME/Documents/WindowsPowerShell/GitAwarePrompt.ps1

Without the dot and space, you get nothing. With the dot-sourced script, we have created a prompt function for PowerShell to call, and we get the status of our Git working directory from our command line:

PS C:\Development\git\HelloWorld [helloGit]> "Modify hello.txt" > hello.txt
PS C:\Development\git\HelloWorld [helloGit*]> git commit -a -m "Commit change"
[helloGit]: created 8a7947c: "Commit change"
 1 files changed, 0 insertions(+), 0 deletions(-)
PS C:\Development\git\HelloWorld [helloGit]> git checkout master
Switched to branch "master"
PS C:\Development\git\HelloWorld [master]> "Change hello.txt again" > hello.txt
PS C:\Development\git\HelloWorld [master*]>
PS C:\Development\git\HelloWorld [master*]> cd ..
PS C:\Development\Git>

Setting the default prompt

You can also more permanently modify your PowerShell prompt by putting the script in your PowerShell profile, which is set to something like ~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 by default (if it doesn't exist, you can create it from PowerShell using New-Item $PROFILE -ItemType file -Force). This can be something like the Git-aware prompt shown here, or something more interesting. Be careful you don't slow down your shell too much though: prompt is obviously called on every new line!

Setting up diff and merge tools for Git on Windows

2009-02-03T23:23:00.047+11:00

I finally got tired of reading diff outputs from git on the command line, and decided to hook up a visual diff and merge tool. After piecing together hints from various posts around ye olde intraweb I've now got somethings that works. I am using Git on MSys to get Git working on Windows via a PowerShell command line, but a similar setup might work via Cygwin or via the cmd.exe command line.

Setting up a diff tool

Update 2009-05-20: This approach stopped working for me when I upgraded to Windows 7 and Git 1.6.3. I had to switch to using git difftool instead.

The easiest way I found to do this was to create a shell script wrapper for your diff tool of choice. To make things easy on me I put the script, git-diff-wrapper.sh in C:\Program Files\Git\cmd, which is in my Path environment variable. The file contents looks like this:

#!/bin/sh

# diff is called by git with 7 parameters:
#  path old-file old-hex old-mode new-file new-hex new-mode
"C:/Program Files/SourceGear/DiffMerge/DiffMerge.exe" "$2" "$5" | cat

#"C:/Program Files/WinMerge/WinMergeU.exe" "$2" "$5" | cat
#"C:/Program Files/KDiff3/kdiff3.exe" "$2" "$5" | cat

The basic format of this is stolen directly from this post on the Msysgit site. Provided your diff tool can be called from the command line, you'll be able to set it up to work with Git using this template. In this case I've used it to setup a call to Sourcefear's DiffMerge, a nice free (as in beer) diff and merge tool.

You'll also see I've commented out calls to WinMerge and KDiff3, which are both free as in beer and speech. I ended up settling on DiffMerge because it is purdy (unlike KDiff3 -- sorry), and also does 3-way merges (unlike WinMerge, which was my previous diff tool of choice).

The next step is telling Git about your wrapper. In your home directory (C:\Users\(username) or the corresponding Documents and Settings equivalent) Git will normally have created a .gitconfig file. If not then go ahead and create one. You'll need to have the following section in there:

[diff]
 external = C:/Program Files/git/cmd/git-diff-wrapper.sh

We can now use git diff and it will fire up our diff tool of choice.

Setting up a merge tool

I had more trouble getting a merge tool working, largely because putting references to paths like C:/Program Files/... in .gitconfig seems to bork when used here. Again I ended up using the wrapper approach, creating git-merge-diffmerge-wrapper.sh at C:\Program Files\Git\cmd to call DiffMerge. This file ended up looking like this:

#!/bin/sh

# Passing the following parameters to mergetool:
#  local base remote merge_result

"C:/Program Files/SourceGear/DiffMerge/DiffMerge.exe" "$1" "$2" "$3" --result="$4" --title1="Mine" --title2="Merging to: $4" --title3="Theirs"

I unashamedly stole this from Alexander Groß's post on getting DiffMerge running on Cygwin-based Git (with slight modifications, any faults are mine :)). We can then wire this up in .gitconfig again:

[merge]
    tool = diffmerge

[mergetool "diffmerge"]
 cmd = git-merge-diffmerge-wrapper.sh "$PWD/$LOCAL" "$PWD/$BASE" "$PWD/$REMOTE" "$PWD/$MERGED" 
    trustExitCode = false
 keepBackup = false
 
[mergetool "kdiff3"]
    path = C:/Program Files/KDiff3/kdiff3.exe
    keepBackup = false
    trustExitCode = false

Now remember that C:\Program Files\Git\cmd is on my PATH, so I can set the command to call git-merge-diffmerge-wrapper.sh without fully qualifying the path. The details on the arguments are available from the git-mergetool(1) man page. I've also left in a KDiff3 version that seems to work too (Git has some built in support for KDiff3 I think, which is why you can get away with only specifying the path).

Time for a test drive

Let's make sure everything's in working order. I'll open up a PowerShell window and let's see how we go (you'll have to excuse me for using old DOS commands instead of fancy PowerShell ones, I've only just switched to PS after running into various issues with the cmd.exe command line).

PS> mkdir HelloWorld
PS> cd HelloWorld
PS> git init
  Initialized empty Git repository in C:/Development/Git/HelloWorld/.git/
PS> echo Hello World! > hello.txt
PS> git add hello.txt
PS> git commit -m "Initial commit"
  [master (root-commit)]: created 2a2cf34: "Initial commit"
   1 files changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 hello.txt
PS> git checkout -b helloGit
  Switched to a new branch "helloGit"
PS> echo Hello Git! > hello.txt
PS> git add hello.txt
PS> git commit -m "Update from helloGit branch"
  [helloGit]: created e71437b: "Update from helloGit branch"
   1 files changed, 0 insertions(+), 0 deletions(-)
PS> git checkout master
  Switched to branch "master"
PS> echo Hello World! Hello indeed! > hello.txt
PS> git add hello.txt
PS> git commit -m "Update from master"
  [master]: created 5dee19d: "Update from master"
   1 files changed, 0 insertions(+), 0 deletions(-)
PS> git merge helloGit
  warning: Cannot merge binary files: HEAD:hello.txt vs. helloGit:hello.txt

  Auto-merging hello.txt
  CONFLICT (content): Merge conflict in hello.txt
  Automatic merge failed; fix conflicts and then commit the result.

Because I've used echo to stream data into hello.txt the files have ended up in binary mode. Let's ignore that as it is just to get an easy demo going. The important thing is we now have a merge conflict to resolve.

If we now type in git mergetool Git ask's us if we'd like to run our merge tool. We can hit enter and up pops DiffMerge. If you wanted KDiff3, we could have called git mergetool -t kdiff3, or any other merge tool in our .gitconfig (by default the tool specified in the merge.tool config option is used).

PS> git mergetool
Merging the files: hello.txt

Normal merge conflict for 'hello.txt':
  {local}: modified
  {remote}: modified
Hit return to start merge resolution tool (diffmerge):

Resolve the merge conflict however you like and then try this:

PS> echo Wow, it worked! > hello.txt
PS> git diff

Hooray, we have our diff tool working! We can also run commands like git diff HEAD~ HEAD and git diff helloGit master and get the output via our diff tool.

Conclusion

This setup earns the coveted Works on My Machine certification, but even if that's the only place it works then hopefully it still gives you enough information to configure your Windows diff and merge tools for use with Git.

If you hunt down the relevant command line options you should be able to get pretty much any tool working: Beyond Compare, p4merge, TortoiseMerge etc.

Hope this helps.

An introduction to the SOLID principles of OO design

2009-01-21T21:56:00.001+11:00

I would be very hard pressed to go passed Robert "Uncle Bob" Martin's SOLID principles as the single most useful tool for helping me with OO design. Some people seem to have a natural talent for OO design and thinking, and have an innate understanding of these principles without requiring the SOLID formalism. I, on the other hand, find them indispensable.

Unfortunately the names used in the somewhat-cryptic "acronym of acronyms"[1] don't exactly lend themselves to being easily learned (Bob Martin and Scott discussed how this came about on a Hanselminutes episode on SOLID, which is well worth a listen). I thought I'd post my interpretation of the principles as a refresher for myself, and as an introduction for anyone trying the learn the terminology.

I should point out I am far from a guru on this stuff, so if there's any misinformation in here please point it out in a comment or email, so I can correct the post and learn me some OO :).

Single Responsibility Principle

"There should never be more than one reason for a class to change." — Robert Martin, SRP paper linked from The Principles of OOD

My translation: A class should concentrate on doing one thing

The SRP says a class should focus on doing one thing, or have one responsibility. This doesn't mean it should only have one method, but instead all the methods should relate to a single purpose (i.e. should be cohesive).

For example, an Invoice class might have the responsibility of calculating various amounts based on it's data. In that case it probably shouldn't know about how to retrieve this data from a database, or how to format an invoice for print or display.

A class that adheres to the SRP should be easier to change than those with multiple responsibilities. If we have calculation logic and database logic and display logic all mixed up within one class it can be difficult to change one part without breaking others. Mixing responsibilities also makes the class harder to understand, harder to test, and increases the risk of duplicating logic in other parts of the design (decreases cohesion, functionality has no clear place to live).

Violations of the SRP are pretty easy to notice: the class seems to be doing too much, is too big and too complicated. The easiest way to fix this is to split the class.

The main trick in following the SRP is deciding how to define the single responsibility. There may be many ways to dissect a feature into responsibilities, but the ideal way is to use responsibilities that are likely to change independently, hence the official description: "A class should have one, and only one, reason to change".

Open Closed Principle

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." — Robert Martin paraphrasing Bertrand Meyer, OCP paper linked from The Principles of OOD

My translation: Change a class' behaviour using inheritance and composition

Bob Martin's initial paper on the OCP linked from The Principles of OOD attributes the idea to Bertrand Meyer, who wrote that classes should be "open for extension, but closed for modification"[2]. The idea is that we can use OO techniques like inheritance and composition to change (or extend) the behaviour of a class, without modifying the class itself.

Say we have an OrderValidation class with one big Validate(Order order) method that contains all rules required to validate an order. If the rules change, we need to change or OrderValidation class, so we are violating the OCP. If the OrderValidation contained a collection of IValidationRule objects that contained the rules, then we could write Validate(Order order) to iterate through those to validate the order. Now if the rules change then we can just create a new IValidationRule and add it to an OrderValidation instance at run time (rather than to the class definition itself).

Following the OCP should make behaviour easier to change, and also help us avoid breaking existing behaviour while making changes. The OCP also gets us to think about the likely areas of change in a class, which helps us choose the right abstractions required for our design.

If you find you need to modify a similar area of code all the time (for example, validation rules) then it's probably time to apply the OCP and abstract away the changing part of the code. Another sign of a potential OCP violation is switching on a type — if another type is created then we'll have to alter the switch statement. A healthy dose of polymorphism is generally the best treatment. :) I generally think of the OCP as an advertisement for the Template Method and Strategy design patterns.

Liskov Substitution Principle

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it." — Robert Martin, LSP paper linked from The Principles of OOD

My translation: Subclasses should behave nicely when used in place of their base class

The LSP sounds deceptively straightforward — we should be able to substitute an instance of a subclass for its parent class and everything should continue to work. Easy right? Well, actually, no it's not, which is probably why we are often advised to favour composition over inheritance. Ensuring a base class works in any situation the parent does is really hard work, and whenever you use inheritance its a good idea to keep the LSP firmly in mind.

The canonical example of an LSP violation (in fact, the one used in the Hanselminutes episode on SOLID mentioned earlier) is the Square IS-A Rectangle relationship. Mathematically a square is a special case of a rectangle with all sides of equal length, but this breaks the LSP when modelled in code. What should SetWidth(int width) do when called on a Square? Should it set the height as well? What if you have a reference to it via its base class, Rectangle? If you have code that expects one behaviour but gets another depending on which subtype it has, you can wind up with some very hard to find bugs.

LSP violations can be easy to miss until you actually hit the condition where your inheritance hierarchy breaks down (I mean, a square IS-A rectangle, right?). The best way to reduce violations is to keep very aware of the LSP whenever using inheritance, including considering avoiding the problem using composition where appropriate.

Interface Segregation Principle

"Clients should not be forced to depend upon interfaces that they do not use." — Robert Martin, ISP paper linked from The Principles of OOD

My translation: Keep interfaces small and cohesive

The ISP is about keeping interfaces (both interface, and abstract class types of interfaces) small and limited only to a very specific need (a single responsibility even :)). If you have a fat interface then you are imposing a huge implementation burden on anyone that wants to adhere to that contract. Worse still is that there is a tendency for class to only provide valid implementations for a small portion of a fat interface, which greatly diminishes the advantages of having an interface at all (note that these partial implementations violate the LSP, as we can no longer treat all subclasses of the interface equally).

The first time I recognised a violation of the ISP was writing a minimal implementation of an ASP.NET RoleProvider, which required an implementation of the following methods:

public class MyRoleProvider : RoleProvider {
    public override void Initialize(string name, System.Collections.Specialized.NameValueCollection config) { ... }
 public override void AddUsersToRoles(string[] usernames, string[] roleNames) { ... }
 public override string ApplicationName { get { ... } set { ... } }
 public override void CreateRole(string roleName) { ... }
 public override bool DeleteRole(string roleName, bool throwOnPopulatedRole) { ... }
 public override string[] FindUsersInRole(string roleName, string usernameToMatch) { ... }
 public override string[] GetAllRoles() { ... }
 public override string[] GetRolesForUser(string username) { ... }
 public override string[] GetUsersInRole(string roleName) { ... }
 public override bool IsUserInRole(string username, string roleName) { ... }
 public override void RemoveUsersFromRoles(string[] usernames, string[] roleNames) { ... }
 public override bool RoleExists(string roleName) { ... }
}

In my case I just wanted to use ASP.NET's built in facility for securing pages by role in the web.config, which means I needed to implement GetRolesForUser(...) and Initialize(...). Can you guess what the other implementations were? That's right, throw new NotImplementedException();. This is very bad — if we have a RoleProvider instance we have no idea what sub-features it will support. On top of that we also have a lot of useless noise in our class. (If you like the RoleProvider, you might also enjoy the MembershipProvider.)

The way to fix violations like this is to break down interfaces along the lines of responsibilities and apply the SRP. For the RoleProvider case, even if we just split it into IRolesForUserLookup and IRoleManagement (yuk), that would let us only implement what we need. If we need all the features then we can implement both interfaces, but we should not be forcing clients to fake or throw in implementations that are meaningless to them.

Dependency Inversion Principle

"A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions." — Robert Martin, DIP paper linked from The Principles of OOD

My translation: Use lots of interfaces and abstractions

The DIP says that if a class has dependencies on other classes, it should rely on the dependencies' interfaces rather than their concrete types. The idea is that we isolate our class behind a boundary formed by the abstractions it depends upon. If all the details behind those abstractions change then our class is still safe. This helps keep coupling low and makes our design easier to change.

At its simplest, this can just be the difference between referencing an EmployeeFinder class or an IEmployeeFinder interface. The concrete EmployeeFinder class can access a database or a file, but the client class only cares that it meets the IEmployeeFinder contract. Better yet, our client class doesn't have to be tied in any way to the EmployeeFinder class. It could instead use SqlEmployeeFinder, XmlEmployeeFinder, WebServiceEmployeeFinder or MockEmployeeFinder.

Where the DIP starts to become really useful and a bit more profound is in a related concept, Dependency Injection. Dependency Injection is about getting other code to insert the actual dependency instances into our class, so we don't even have the client class newing up any of the concrete instances. This completely isolates our class and makes change and reuse much easier. (I've covered some introductory stuff in a previous ramble on dependency injection).

The other side of the DIP relates to dependencies between high and low level modules in layered applications. For example, a class accessing the database should not depend on a UI form used to display that data. Instead the UI should rely on an abstraction (or abstractions) over the database access class. Traditional application layers (data, logic, ui) seem largely replaced by MVC, onions and hexagons these days, so I tend to think about the DIP entirely from the point of view of abstracting dependencies.

SOLID principles as a whole

You can probably see that the SOLID principles overlap a lot. For example, the SRP provides a good way of splitting interfaces to follow the ISP. The ISP helps implementers conform to the LSP by making implementations small and cohesive. You may also notice that some of the principles contradict, or at least pull in opposing directions, such as the OCP requiring inheritance while the LSP tends to discourage it[3]. This interplay between the principles can provide a really useful guide while developing your design. I'm believe there are no perfect designs, just trade offs, and the SOLID principles can help you evaluate these and achieve a good balance. The fact that there is some measure of conflict between them also makes it obvious that none of the principles should be applied rigidly or dogmatically. Do you really need a huge interface explosion due while adhering to the OCP and DIP? Maybe, maybe not. But considering your design options in light of the SOLID principles can help you decide.

A lot of SOLID principles seem to fall out fairly naturally if you practice TDD (or BDD). For example, writing an effective unit test for a class is much easier if you follow the DIP and isolate your class from its dependencies. If you are writing the tests first to drive your design, then your class will naturally tend to use the DIP. If you are retro-fitting tests, then you'll likely encounter more difficulties testing, and may end up with interaction-style tests, re-writing the class to use the DIP, or worse, throwing it in the too hard-to-test basket.

This is what people mean when they say that TDD and "testability" is not about testing, it is about design. Scott Bellware recently published a good post on design, SOLID and testability that goes into this in more detail.

Conclusion

This has been a quick introduction to the SOLID principles. Hopefully it will make it easier for people to jump into the gory details of all the principles. Even if you have an innate grasp on these principles, I think it is worth going to the trouble to learn them, if only to help get a common language with which to discuss these principles.

References

[1] Yammer exchange with Xerxes
[2] Bertrand Meyer, Object-Oriented Software Construction
[3] Gene Shadrin, Three Sources of a Solid Object-Oriented Design, SYS-CON Media Inc.

Happy 2nd Blogoversary

2008-12-09T23:15:00.006+11:00

In a couple of days I will have been blogging for two years. Please excuse a little self-indulgence on my part while I go through the usual blogoversary formalities.

Some random statistics

Most of this is from Google Analytics, which should be a semi-decent approximation to reality.

264 posts
Around 130 valued feed subscribers (including some which aren't just me subscibing from different PCs). :)
Over 30,000 visits and over 40,000 page views since August 2007. Most recently there's been about 3,000 visits a month. Not a huge amount, but probably more than this little blog warrants. :)
Busiest day: 768 visits on 3rd April 2008, thanks to a Reddited Python post.
Browser usage: Firefox 50%, IE 42%, Opera, Chrome and Safari around 2% each.
OS usage: Windows 92%, Mac 4%, Linux ~4%
17 visits from iPhones. Apparently one from an HPUX :)
262 visits from Microsoft.
Visits from 141 countries, with most from US, UK, India, Australia and Canada. Slightly less visits from Gibraltar, Maldives, Liechtenstein, and Madagascar :)
Search engine stats: Google 99.36%. Yahoo came second. I'm guessing Blogger.com bias. :)

Most visited posts

The Python and ORM posts were due to unsolicited Redditing and DotNetKicking. The others care of Google.

Posts I like but no one visited :)

Proving once and for all that just because you build it doesn't mean that they will come.

Explaining good code to non-geeks. After reading this interested family members started to grok what I do for a living :)
Implementing Python-like Range in C#
Fluently constructing test objects
BDD test naming with AutoHotKey. Picked up by the legendary JP Boodhoo. Yes, I'm blushing :)
Yet another way of raising events from mocks, which ended up getting into Rhino Mocks 3.5.
NHibernate mappings using xml, attributes, and Fluent NHibernate
Attempting to understand dependency injection
An assortment of basic TDD tips
Getting to grips with ReSharper. Bit old but still reasonably relevant.
Learning C# lambda syntax from delegates

Where to from here?

The purpose of my blog remains the same as last year: a way of helping me learn stuff. I still find blogging to be one of the best ways for me to solidify a concept in my mind.

I've found with my new job (~5 months) I've been doing tonnes of coding in an Agile, TDD-toting team, and so a lot of my time and learning goes on there. My work also has an enormous library of text books which I've been working through, and I'm also tending (with the exception of this post :)) to be a bit more selective about what I post, so a lot of my Frankenstein-like learning experiments never see the light of a browser. All this has made my blog a bit quieter of late, but hopefully this has meant a higher signal-to-noise ratio over the last couple of months.

Thanks to everyone that's subscribed, commented, or visited my little patch of the intraweb -- it's great to think that my ramblings occasionally help out. :)

System.BadImageFormatException on 64-bit OS

2008-12-02T12:03:00.006+11:00

I got the following exception when running the unit tests as part of a local build of our .NET project today:

System.BadImageFormatException : Could not load file or assembly '(assembly name)' or one of its dependencies. 
An attempt was made to load a program with an incorrect format.

This seemed a bit odd, because the build was working on every other machine. Even odder, the build and tests ran fine within Visual Studio.

Turns out this occurs when the CLR tries to load an assembly that contains unmanaged code built targeting a different platform. In my case, I was running it on my new machine which has 64-bit Vista, but one of the referenced assemblies contained native code compiled targeting x86. It was running fine in Visual Studio because VS is a 32-bit app, and so was calling everything in 32-bit mode via WoW64.

The solution? Build both 32-bit and 64-bit versions of the assembly causing the problem, or force our project to always run in 32-bit mode (within WoW64 on x64 machines) by specifically setting the platform target to x86 in the Visual Studio project build options (by default this is set to "Any CPU").

Hope this saves someone some hair-tearing. :)

Update: I have found the Corflags tool invaluable for flagging a DLL as needing to run under the 32 bit CLR. This is useful when you don't have the source to recompile the app, and has been put to good use getting the old, free version of NCover to run on a 64-bit bit OS. A good write up on Corflags is here.

References:

MSDN thread on this error with an EF pre-release

Bookmarklet to get commit message for JIRA integration

2008-11-26T12:30:00.002+11:00

At my work we use JIRA for issue tracking, and the FishEye plugin to integrate with our source control system. This means that for each commit against an issue we need to start our commit message with details of the issue so that JIRA/FishEye can pick it up. For example:

DAVE-1234 (Pairing with Dave is annoying)

* Updated code to crash while Dave is around, so pairing can finish.

Here "DAVE-1234" is the issue number, and "Pairing with Dave is annoying" is the issue title. Speaking of annoying, it was becoming so to copy and paste the issue number and title from the issue's JIRA page, as the values do not appear together in our current page template. So I thought I would write up a bit of javascript to parse the details directly from the JIRA page. Yes, I would be better off getting the page template updated, but I've been intending to do that for weeks, so horrible-javascript-hack-over-lunch it is. :)

The title of the JIRA page for an issue has all the information we need:

[#DAVE-1234] Pairing with Dave is annoying - Your JIRA Instance Name

You can hackily parse this using javascript:

var title = document.title;

var endOfIssueKeyIndex = title.indexOf("]");
var endOfIssueNameIndex = title.lastIndexOf(" - ");
var issueKey = title.substring("[#".length, endOfIssueKeyIndex);
var issueName = title.substring(endOfIssueKeyIndex + "] ".length, endOfIssueNameIndex);

window.alert(issueKey + " (" + issueName + ")");

If you prefix that with javascript: and copy and paste it into the location field of a FireFox bookmark, you can click on the bookmark to throw up an alert containing the text formatted as required (this will probably work on other browsers with a little tweaking as well). You can then CTRL+A to select the text and CTRL-C to copy it. If you put the bookmark on your FireFox bookmarks toolbar this almost becomes useful. :)

FireFox reformats the bookmark location automatically, but here is what you end up with for completeness' sake:

javascript:var%20title%20=%20document.title;%20%20var%20endOfIssueKeyIndex%20=%20title.indexOf("]");%20var%20endOfIssueNameIndex%20=%20title.lastIndexOf("%20-%20");%20var%20issueKey%20=%20title.substring("[#".length,%20endOfIssueKeyIndex);%20var%20issueName%20=%20title.substring(endOfIssueKeyIndex%20+%20"]%20".length,%20endOfIssueNameIndex);%20%20window.alert(issueKey%20+%20"%20("%20+%20issueName%20+%20")");

It's also possible to get javascript to copy this directly to your clipboard, but it takes a bit more mucking around. It will obviously stuff up if your JIRA title is in a different format, or if you go around running it on arbitrary web pages :), but it works on my machine -- hope it works on yours too! :)

Unusual formatting with test-first extension method abuse

2008-10-28T22:53:00.003+11:00

My pair and I were looking at performing some unusual string formatting today. We kept finding that the extension methods in System.Linq.Enumerable were pretty helpful, but they often seemed to fall just short of what we needed to make the code really readable. Once I got home I thought I'd see how far I'd get by dumping some functionality into extension methods with blatant disregard for the potential consequences. (Unfortunately I had to miss the Sydney ALT.NET meeting tonight, so I had a bit of time to play around.)

Formatting arrays for acceptance tests

Here is the basic behaviour we're after. Given an array or other enumerable of integers (or of any type with a sensible ToString() method really), we want to return the items as a single, comma separated string. The strange part of it is that if every value in the enumeration is the same, we just want to return that one value as a single string. The reason for this unusual behaviour is to help get some easily usable output for the acceptance test framework we are using.

As this is just a helper for acceptance tests (i.e. we won't be polluting namespaces in production code) I'll dump this functionality onto any IEnumerable<T> using an extension method.

Starting test first

Let's start with an easy case: what should happen when we have an empty enumerable?

[TestFixture]
public class FixtureFormatterTests {
    [Test]
    public void Empty_array_should_format_as_empty_string() {
        var emptyArray = new int[0];
        Assert.That(emptyArray.ToFixtureString(), Is.EqualTo(string.Empty));
    }
} 

public static class HelperExtensions {
 public static string ToFixtureString<T>(this IEnumerable<T> enumerable) {
   return string.Empty;
 }
}

After that monumentally brilliant piece of code, let's add the comma-separated string part of the requirement.

[Test]
public void Array_with_different_values_should_give_comma_separated_string() {
 var ints = new[] {1, 2, 3, 4};
 Assert.That(ints.ToFixtureString(), Is.EqualTo("1,2,3,4"));            
}

Now we'll get it to pass. We'll lean heavily on the built-in String.Join(String, String[]) method to do the work for us.

public static string ToFixtureString<T>(this IEnumerable<T> enumerable) {
 if (enumerable.Count() == 0) return string.Empty;
 return string.Join(",", enumerable.Select(item => item.ToString()).ToArray());
}

This passes, but it's a bit ugly. Let's look at refactoring.

First refactoring

First, I've got a feeling that if our enumerable is empty, String.Join(...) won't concatenate anything, and so will just return an empty string. This would render our first line redundant.

public static string ToFixtureString<T>(this IEnumerable<T> enumerable) {
 return string.Join(",", enumerable.Select(item => item.ToString()).ToArray());
}

It still passes both our tests so we are safe (I love unit tests :)). We also have that ugly bit of code where we are translating our IEnumerable<T> into an array of strings, using the Select() extension method. As I'm keen to start over using extensions methods, let's hide all that away in a Python-like join() method. Python's join() works like this:

>>> ints = [1,2,3,4]
>>> ",".join(str(i) for i in ints)
'1,2,3,4'

I'd like to do that, but abstract away the sequence/enumerable to string conversion. Let's do this using an extension method to char:

public static string Join(this char separator, IEnumerable enumerable) {
 return string.Join(separator.ToString(), enumerable.Select(item => item.ToString()).ToArray());
}

public static string ToFixtureString(this IEnumerable enumerable) {
 return ','.Join(enumerable);
}

Assuming you know the whole "Join" concept, our ToFixtureString() method is now pretty darned clean :). The original ugliness is now moved to the Join() method, but at least it is all directly related to the purpose of that method. In its original spot I think it obscured the intention behind the ToFixtureString() method.

Completing our `ToFixtureString()` requirements

The last requirement we have for this is to only show one value if all the items in the enumerable are the same.

[Test]
public void Array_with_the_same_values_should_return_that_value_as_a_single_string() {
 const int value = 2;
 var ints = new[] {value, value, value};
 Assert.That(ints.ToFixtureString(), Is.EqualTo(value.ToString()));
}

Here's an attempt at get this to pass.

public static string ToFixtureString<T>(this IEnumerable<T> enumerable) {
 var firstItem = enumerable.First();
 if (enumerable.All(item => item.Equals(firstItem)))
 {
  return firstItem.ToString();
 }
 return ','.Join(enumerable);
}

This fails our Empty_array_should_format_as_empty_string test because the enumerable.First() call throws with InvalidOperationException: Sequence contains no elements. So we're back to that enumerable.Count() == 0 line, which gets all our tests passing again.

public static string ToFixtureString<T>(this IEnumerable<T> enumerable) {
 if (enumerable.Count() == 0) return string.Empty;
 var firstItem = enumerable.First();
 if (enumerable.All(item => item.Equals(firstItem)))
 {
  return firstItem.ToString();
 }
 return ','.Join(enumerable);
}

Refactoring out the empty enumerable check

I don't like enumerable.Count(). It needs to go through the entire enumerator to get the count, when we really only care if the enumerable is empty. Sounds like time for some more extension method abuse. Here's some tests that require adding an IsEmpty() extension method to IEnumerable<T>:

[TestFixture]
public class IsEmptyEnumerableTests {
 [Test]
 public void Empty_enumerable() {
  Assert.That(new int[0].IsEmpty());
 }

 [Test]
 public void Non_empty_enumerable() {
  Assert.That(new[]{1,2,3}.IsEmpty(), Is.False);
 }
}

public static class HelperExtensions {
 //...  
 public static bool IsEmpty<T>(this IEnumerable<T> enumerable) {
  return !enumerable.GetEnumerator().MoveNext();
 }
}

This is a bit hacky, but means we only need to to see if our enumerator has a single item to determine whether it is empty, and we can make our ToFixtureString() method a bit more expressive as a result:

public static string ToFixtureString<T>(this IEnumerable<T> enumerable) {
 if (enumerable.IsEmpty()) return string.Empty;
 var firstItem = enumerable.First();
 if (enumerable.All(item => item.Equals(firstItem))) {
  return firstItem.ToString();
 }
 return ','.Join(enumerable);
}

Vague semblance of a conclusion

We now have our unusual formatting covered, and IsEmpty() and Join() extension methods to help make our code a bit cleaner. I'm not advocating this kind of thing for every day use, but I think it shows how useful extension methods can be to make your code more expressive. It comes at the cost of changing classes that most .NET developers are familiar with, so it's definitely something to be careful with.

Learning C# lambda syntax from delegates

2008-10-22T01:21:00.008+11:00

As a sweeping generalisation, I've found that developers who are really proficient with delegates / anonymous delegates seem to have a bit of an adverse reaction to seeing the lambda syntax in C# .NET 3.5. Luckily I'm proficient with very little, so the transition was easy for me :). This is a post to try and make the transition easier for people more competent than me :).

From delegates to lambdas

Say I have a Widget class, which just contains a Name and a WeightInGrams.

public class Widget {
        public Widget(string name, int weightInGrams) {
            Name = name;
            WeightInGrams = weightInGrams;
        }
        public string Name { get; set; }
        public int WeightInGrams { get; set; }
    }
}

Now we want to search through an array of these and find how many are under 300 grams. Why? Er, why not? We'll use Array.FindAll to do this old skool (as opposed to fancy LINQy stuff like using Where()). FindAll takes an array of type T and a Predicate<T>, which is a delegate that takes a T and returns a bool indicating whether the predicate has been matched.

[TestFixture]
public class LambdaTests {
 [Test]
 public void SearchArrayUsingDelegate() {
  var widgets = SixWidgetsFrom100GramsTo600Grams();
  var widgets300GramsOrLess = Array.FindAll(widgets, Weighs300GramsOrLess);
  Assert.That(widgets300GramsOrLess.Length, Is.EqualTo(NumberOfWidgets300GramsOrLess));
 }

 private bool Weighs300GramsOrLess(Widget widget) {
  return widget.WeightInGrams <= 300;
 }

 private const int NumberOfWidgets300GramsOrLess = 3;
 static Widget[] SixWidgetsFrom100GramsTo600Grams() {
  return new[] {
    new Widget("W1", 100), new Widget("W2", 200), new Widget("W3", 300),
    new Widget("W4", 400), new Widget("W5", 500), new Widget("W6", 600)
     };
 }
}

As of .NET 2.0 we can use an anonymous delegate to do this inline:

[Test]
public void SearchArrayUsingAnonymousDelegate() {
 var widgets = SixWidgetsFrom100GramsTo600Grams();
 var widgets300GramsOrLess = 
  Array.FindAll(widgets, delegate(Widget widget) { return widget.WeightInGrams <= 300; });
 Assert.That(widgets300GramsOrLess.Length, Is.EqualTo(NumberOfWidgets300GramsOrLess));
}

As of .NET 3.5 we have lambda syntax, which provides a terser way of expressing our predicate function:

[Test]
public void SearchArrayUsingLambda() {
 var widgets = SixWidgetsFrom100GramsTo600Grams();
 var widgets300GramsOrLess = 
  Array.FindAll(widgets, widget => widget.WeightInGrams <= 300);
 Assert.That(widgets300GramsOrLess.Length, Is.EqualTo(NumberOfWidgets300GramsOrLess));
}

Clear as mud? Let's have a closer look at how we convert from delegate to a lambda expression.

//Original delegate:
delegate(Widget widget) { return widget.WeightInGrams <= 300; }

//Drop the "delegate" keyword, and add a funky "=>" operator, which goes by all sorts of creative names :)
(Widget widget) => { return widget.WeightInGrams <= 300; }

//The C# 3.0 compiler has type inference, so we can also drop the argument type and let the compiler figure it out.
//If we have a single statement to the right of the "=>" operator, this will be returned from the function,
//so we can also drop the braces, end-of-statement semicolon and the explicit return.
widget => widget.WeightInGrams <= 300

So what's the difference between our anonymous delegate and our lambda expression? In this example, absolutely nothing other than a terser (and somewhat addictive IMO) syntax. Let's compare the generated code for both just to prove this:

[CompilerGenerated]
private static bool <SearchArrayUsingAnonymousDelegate>b__0(Widget widget) {
    return (widget.WeightInGrams <= 300);
}
[CompilerGenerated]
private static bool <SearchArrayUsingLambda>b__2(Widget widget) {
    return (widget.WeightInGrams <= 300);
}

So based on this example anonymous delegates and lambdas are exactly the same, it's just a matter of getting used to writing a bit less noise code. :)

Exactly the same, except when they're different...

Of course there's a catch. Actually, I can think of two, and they both relate to expression trees. To support a lot of LINQ magic, lambda expressions can be converted to expression trees at compile time. An expression tree is basically just a bunch of objects representing each part of the lambda expression. A query provider, like the one provided by LINQ to SQL, can then process the expression tree and execute the expression in a different way, say, by converting it to TSQL and running it against database.

To get the compiler to generate an expression tree from a lambda expression we just need to specify the type differently:

Predicate<Widget> lambda = widget => widget.WeightInGrams <= 300;
Expression<Predicate<Widget>> expressionTree = widget => widget.WeightInGrams <= 300;

So how does this relate to differentiating anonymous delegates and lambdas?

//Compiles fine:
Expression<Predicate<Widget>> expressionTree = widget => widget.WeightInGrams <= 300;

//WON'T COMPILE:
Expression<Predicate<Widget>> expressionTree = delegate(Widget widget) { return widget.WeightInGrams <= 300; };
/* error CS1946: An anonymous method expression cannot be converted to an expression tree */

As you can see from the code sample above, the compiler will simply refuse to convert the delegate form to an expression tree. So the way the compiler handles the two are quite different as soon as you introduce expression trees. I also mentioned a second catch. Take a look at this modification of the previous example:

//WON'T COMPILE:
Expression<Predicate<Widget>> expressionTree = widget => { return widget.WeightInGrams <= 300; };
/*  error CS0834: A lambda expression with a statement body cannot be converted to an expression tree */

This second catch is that there is actually a difference between lambda expressions and lambda statements. A lambda statement contains braces and a function body, and can potentially have multiple lines like a standard delegate. A lambda expression is the single line with an implicit return. So in our original, Array-searching example, the following two statements are actually are different if you are trying to assign them to expression trees.

//Lambda statement
widget => { return widget.WeightInGrams <= 300; }

//Lambda expression
widget => widget.WeightInGrams <= 300

Aside: In case you were wondering, here is the expression tree generated by the compiler for the widget => widget.WeightInGrams <= 300 lambda expression, care of Reflector:

ParameterExpression CS$0$0000;
Expression<Predicate<Widget>> expressionTree = 
  Expression.Lambda<Predicate<Widget>>(
 Expression.LessThanOrEqual(
  Expression.Property(
   CS$0$0000 = Expression.Parameter(typeof(Widget), "widget"), 
   (MethodInfo) methodof(Widget.get_WeightInGrams)), 
   Expression.Constant(300, typeof(int))), 
   new ParameterExpression[] { CS$0$0000 }
  );

Conclusion

So in conclusion, lambdas are simply, for most intents and purposes, a neater syntax for defining delegates.

//Delegate:
delegate(Widget widget) { return widget.WeightInGrams <= 300; }

//Drop the delegate and add the "=>" operator to get a lambda statement
(Widget widget) => { return widget.WeightInGrams <= 300; }

//Use type inference and implicit return to get a lambda expression
widget => widget.WeightInGrams <= 300

The only differences that can bite you are when you are dealing with expression trees, either explicitly via the Expression<> type, or implicitly by using the LINQ operators. Hope this helps, or at least has caused no significant damage to your understanding of lambdas :)

The (very) basics of AAA with Rhino Mocks 3.5

2008-10-01T23:16:00.022+10:00

A small contingent from my work made the trek out to the first Sydney ALT.NET meeting last night. It was great to be in a room full of people all intent on finding better ways to develop software. Afterward I was dragged kicking and screaming (</sarcasm> :)) by my colleagues to a local pub for debriefing over beers and a laptop. One topic discussed was the Arrange, Act, Assert (AAA) style of mocking using Rhino Mocks 3.5.

I thought I'd quickly run through my (admittedly basic) understanding of AAA, as I tend to use a slightly different approach to the one shown in the meeting. If I've got anything hideously wrong please leave a comment and let me know. I'm not going to cover anything about how to use mocking, but will just attempt to outline the difference between record/replay and AAA.

Record / Replay semantics

The traditional way of mocking has been to use record/replay. This means you record a number of expectations against a mock object, then change the mock to replay mode and exercise the subject under test (SUT). In replay mode, the mock will throw an exception if an unexpected method is called (for strict mocks). The final step is to verify the expectations you recorded, which will throw an exception if one of the expected methods was not called.

Let's have a look at one of my dodgy-as-usual examples (probably even worse than normal, as it was written in a pub around 11 pm after a long day :))

public interface IEmailService {
    void Send(MailMessage msg);
}

public class InvoiceSender {
    private readonly IEmailService emailService;
    public InvoiceSender(IEmailService emailService) {
        this.emailService = emailService;
    }

    public void SendInvoice(float amount, string to) {
        var msg = new MailMessage("me@me.com", to, "Invoice", string.Format("Please pay {0}", amount));
        emailService.Send(msg);
    }
}

Our subject under test is InvoiceSender, and we want to verify that the IEmailService.Send(MailMessage) method is being called from SendInvoice(float, string).

[Test]
public void Send_invoice_using_email_service_with_record_replay() {
 var mockRepo = new MockRepository();
 var mockEmailer = mockRepo.DynamicMock<IEmailService>();            
 var invoiceSender = new InvoiceSender(mockEmailer); 
 //Record expecations
 mockEmailer.Expect(service => service.Send(null)).IgnoreArguments() ; 
 mockRepo.ReplayAll();
 //Exercise SUT
 invoiceSender.SendInvoice(1.0F, "me@me.com");  
 //Verify expectations
 mockRepo.VerifyAll();            
}

Here we've used Rhino Mocks to generate a mock implementation of the IEmailService interface. We have recorded a single expectation against it: it is expecting to have its Send(...) method called with any argument (hence the IgnoreArguments() call -- for non-pub code we would probably want to check the argument).

We then use ReplayAll() to switch to replay mode, which tells our mocks that we have finished recording expectations and are ready to see what is really called on our mock. We then exercise the SUT, and verify that our expectations were met (i.e. Send() was called on our mock). The test passes -- victory is ours!

Writing the test using AAA

There's nothing really wrong with the record/replay approach. If you like it that's great! Some people find it confusing (or at least unnatural), probably because it doesn't quite fit the four phase test structure used for state-based testing (Setup, Exercise, Verify, Teardown).

The AAA approach lets us use a more state-based testing approach with our mocks. Let's rewrite our previous test using AAA:

[Test]
public void Send_invoice_using_email_service_with_AAA() {
    //Arrange
    var mockEmail = MockRepository.GenerateMock<IEmailService>();
    var invoiceSender = new InvoiceSender(mockEmail);
    //Act
    invoiceSender.SendInvoice(1.0F, "me@me.com");
    //Assert
    mockEmail.AssertWasCalled(service => service.Send(Arg<MailMessage>.Is.Anything)); 
}

Here we are creating our mock using the new static GenerateMock<T>() method introduced in Rhino Mocks 3.5. We then exercise the SUT with an identical line of code to the one used in the first test. Finally, we assert that the Send() method on our mock was called as we expected. The test passes -- again we are victorious!

First couple of things to notice are that we have no mention of recording or replaying expectations, and we've used less lines of code. Our test also fits in with the four phase test structure: Arrange -> Setup, Act -> Exercise, Assert -> Verify, with optional Teardown. This avoids mixing expectations and assertions throughout the test. Depending on your prior experience with record/replay, you might find this easier to read and understand than our first test.

Under the hood Rhino Mocks is still going off and doing pretty much the same thing as its always done. The static GenerateMock<T>() method simply creates a dynamic mock already in replay mode. The mock remembers all calls against it, and we can then use AssertWasCalled() and other methods to check these calls and make sure the ones we want are there.

Aside: One of the issues raised during the Sydney ALT.NET meeting was mocks vs. stubs. I think AAA makes the distinction a bit more apparent. You'll tend to use a stub during the Arrange part of your test to provide indirect inputs to the SUT, whereas you will use mocks to verify behaviour and indirect outputs of the SUT during the Assert phase. From the Rhino Mocks wiki page on 3.5 (rev. 40), "A stub will never cause a test to fail", whereas mocks will fail if the expectations on them aren't met.

This is only a very simplistic example to illustrate the basic differences for each approach. For more realistic cases the benefits of AAA become more apparent (see Jimmy Bogard's post on AAA with BDD tests for a good example).

These couple of lines of code are available from my Google Code repository if you want run the tests and have a bit of a play around: DaveSquared.MockSample.zip.

Sydney ALT.NET group

2008-09-09T13:04:00.000+10:00

Just wanted to quickly pass on the announcement that a Sydney ALT.NET group is starting up. First meeting is at the Thoughtworks office in the city on 30th September.

Hopefully this will do well -- I'd love a group in Sydney where we can focus on software development practices in .NET, with specific tools and technologies taking a bit of a back seat.

NHibernate mappings using xml, attributes, and Fluent NHibernate

2008-09-04T23:25:00.006+10:00

A few of us at work have been looking at NHibernate 2.0 as a potential ORM tool for our next project. The initial reactions have included (but weren't limited to) shudders of horror at seeing the mass of angle brackets present in the .hbm.xml mapping files. I don't think this reaction is atypical -- I thought the same thing when I first tried NHibernate. However once I started using it (not for anything serious mind you, just for personal projects. I'm at pre-newbie stage still :)), I found the XML relatively painless. In fact once I'd set them up initially it was great to be able to deal with ordinary POCO (Plain Old C# Object) classes and only think about the persistence mappings when tweaking the DB.

That said, there are alternatives hand coding the .hbm.xml mapping files. I thought I'd cover a few of the options here: NHibernate Mapping Attributes, and Fluent NHibernate.

Getting started

I decided to reuse the extra-simple scenario from my ORM roundup posts. I have a table of suppliers, and a table of states (or provinces, territories, prefectures etc.). Both suppliers and states have names, which are stored as strings/varchars, and IDs, which are stored as Guids/uniqueidentifiers. Each supplier can service many states. So we have a simple many-to-many relationship between the two main entities. It looks a bit like this:

Now let's create some POCOs for to model our suppliers and states. I've added these to an Entities folder in an otherwise blank C# Class Library project.

//State.cs
using System;
namespace Workshop.Entities {    
    public class State {
        public virtual Guid StateId { get; set; }        
        public virtual String Name { get; set; }
    }
}
//Supplier.cs
using System;
using System.Collections.Generic;
namespace Workshop.Entities {
    public class Supplier {
        private IList<State> statesServiced = new List<State>();
        
        public virtual Guid SupplierId { get; set; }
        public virtual String Name { get; set; }
        public virtual IList<State> StatesServiced { get { return statesServiced; } set { statesServiced = value; } }
    }
}

These are nice ordinary classes, with no consideration given as to how they will be persisted. The only concession we have made is making everything virtual by default, so that it is easy for NHibernate to create proxies from these classes.

I'll also throw in an App.config so NHibernate knows which database to talk to. This time around I'm using NHibernate 2.0, which has a new configuration format from the last time I looked at this example.

Hand coding Hibernate Mapping Files

Time to map our entity classes to our database. Let's start off with the standard, hand coded .hbm.xml approach. We'll create a State.hbm.xml file and a Supplier.hbm.xml file to hold our mappings. We'll also set these files to be compiled in as embedded resources so we can get NHibernate to load the mappings from our DLL (in VS, right click the files in the Solution Explorer and edit the Build Action property).

<!-- State.hbm.xml -->
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Workshop" namespace="Workshop.Entities">
  <class name="State" table="State">
    <id name="StateId" type="guid">
      <generator class="guid" />
    </id>
    <property name="Name" type="String" />
  </class>
</hibernate-mapping>

<!-- Supplier.hbm.xml -->
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Workshop" namespace="Workshop.Entities">
  <class name="Supplier" table="Supplier">
    <id name="SupplierId" type="guid">
      <generator class="guid" />
    </id>
    <property name="Name" type="String" />
    <bag name="StatesServiced" table="Supplier_StatesServiced">
      <key column="SupplierId" />
      <many-to-many column="StateId" class="State" />
    </bag>
  </class>
</hibernate-mapping>

Here we are just telling NHibernate how to map each bit of entity data to the database schema. The HBM files include which main table is used to persist each entity, describes each entity's primary key and standard properties, as well as how the entities relate to each other (in this case we have a many-to-many mapping, using a bag collection). These files are explained in more detail in my Messing around with NHibernate post.

Testing our mappings

I've populated my database with some sample data (I actually did it using NHibernate -- I find it easier to fill in the relationships that way than with hand written SQL). Let's create an NHibernateTests.cs file and add a test to make sure the entities are mapped correctly.

public class NHibernateTests {
 protected static readonly ISessionFactory SessionFactory = getSessionFactory();
 
 private static ISessionFactory getSessionFactory() {
  Configuration config = new Configuration();
  config.AddAssembly(Assembly.GetExecutingAssembly());
  return config.BuildSessionFactory();
 }
 
 [Fact]
 public void Get_suppliers_servicing_NSW() {
  using (ISession session = SessionFactory.OpenSession()) {
   var suppliers = session
    .CreateCriteria(typeof(Supplier))
    .CreateCriteria("StatesServiced")
    .Add( Restrictions.Eq("Name", "NSW") )
    .SetProjection( Projections.Property("Name") )
    .List<String>();
   session.Close();
   Assert.NotEmpty(suppliers);
   Assert.Equal(4, suppliers.Count);
   Assert.Contains("Tea Ah Maria", suppliers);
   Assert.Contains("Teas'r'us", suppliers);   
  }
 } 
}

This code intialises a new ISessionFactory using the configuration settings in the App.config, and the config.AddAssembly(Assembly.GetExecutingAssembly()); line adds the .hbm.xml mappings embedded in our DLL.

I've also used the Get_suppliers_servicing_NSW() test to run a query against all the mapped entities. I'll run this test for each configuration change I make to ensure I haven't broken anything. The details of the test itself aren't really important, but if you are interested it just asks NHibernate to get suppliers that service the state of NSW, and then uses a projection to only bring back the name of the supplier. The assertions check that the expected number of supplier names are returned, and makes sure the list of names includes a couple of the expected values.

NHibernate Mapping Attributes

NHibernate Mapping Attributes (also know as NHMA) is a part of the NHibernate Contrib project, and can be used to declare mappings via attributes directly on your entities classes. This sort of spoils the whole POCO idea, but has the advantage of allowing you to make changes to the entity and it's mapping in the one spot. Let's see how this changes our Supplier and State classes.

//State.cs
[Class]
public class State {
 [Id(0, Name="StateId", TypeType=typeof(Guid), Column="StateId")]
 [Generator(1, Class="guid") ]
 public virtual Guid StateId { get; set; }        

 [Property]
 public virtual String Name { get; set; }
}

//Supplier.cs
[Class]
public class Supplier {
 private IList<State> statesServiced = new List<State>();
 
 [Id(0, Name="SupplierId", TypeType=typeof(Guid))]
 [Generator(1, Class = "guid")]        
 public virtual Guid SupplierId { get; set; }
 
 [Property]
 public virtual String Name { get; set; }
 
 [Bag(0, Table="Supplier_StatesServiced")]
 [Key(1, Column="SupplierId")]
 [ManyToMany(2, Column="StateId", ClassType = typeof(State))]
 public virtual IList<State> StatesServiced { get { return statesServiced; } set { statesServiced = value; } }
}

We no longer need our .hbm.xml files, and have instead translated the relevant mapping information to attributes on the classes themselves. By using attributes NHMA can infer some of the mapping information we previously had to enter explicitly (for example, <property name="Name" type="String" /> just becomes [Property] public virtual String Name {...}), and we have traded our angle brackets for square ones :). There are also a few strange things going on here. Look at this extract from Supplier.cs:

 [Id(0, Name="SupplierId", TypeType=typeof(Guid))]
 [Generator(1, Class = "guid")]        
 public virtual Guid SupplierId { get; set; }

Notice the element indexes on the attributes (ID is 0, Generator is 1)? This is because NHMA is actually generating your .hbm.xml on the fly from the attributes, and it needs to know the order in which to write out the XML elements (attribute order isn't maintained using reflection). To further illustrate this attribute to XML translation, let's look at how this affects our ISessionFactory initialisation for our tests:

//In NHibernateTests.cs
private static ISessionFactory getSessionFactory() {
 var config = new Configuration();            
 HbmSerializer.Default.Validate = true;                        
 HbmSerializer.Default.Serialize(System.Environment.CurrentDirectory, Assembly.GetExecutingAssembly());
 config.AddDirectory(new DirectoryInfo(System.Environment.CurrentDirectory));            
 return config.BuildSessionFactory();
}

This is using the NHMA default HbmSerializer class to generate .hbm.xml files in the current working directory. We then load in these mapping files just like before (except we are using the file system and not embedded assembly resources).

So to my way of thinking all we have really achieved is simply rewritten all our original .hbm.xml logic as attributes rather than XML, and made our previously nice clean POCO entities cluttered with persistence information and subsequently less readable. I really loved the idea of NHMA at first, but after trying it out I can't really see it providing much benefit over ye olde hand coded XML. As an added deterrent I couldn't really find much documentation on NHMA, so I ended up having to translate from the fairly well documented .hbm.xml format anyway.

Fluent NHibernate

Fluent NHibernate, like NHMA, offers a non-XML way to configure your mappings. Instead of using attributes though, we are using standard .NET code via a fluent interface. This provides lots of neat advantages like automated refactoring and some compile time support, as well as being able to eliminate duplicated information between .hbm.xml and the POCO entities themselves by using customisable conventions and inferring the relevant property types and names. Before we dive into this it's worth noting that Fluent NHibernate hasn't been released yet and so still has some rough edges. I'm using revision 80 from the project's SVN repository, so much of this will probably change before it hits version 1.0.

I've reverted our Supplier and State classes back to Plain Old CLR Objects (removed all the NHMA attributes) and also taken out the .hbm.xml files. The first thing we need to do is create some Fluent Nhibernate ClassMap classes.

public class StateMap : ClassMap<State> {
 public StateMap() {                
  Id(x => x.StateId);
  Map(x => x.Name);
 }
}

public class SupplierMap : ClassMap<Supplier> {
 public SupplierMap() {                
  Id(x => x.SupplierId);
  Map(x => x.Name);
  HasManyToMany<State>(x => x.StatesServiced)
   .AsBag()
   .WithTableName("Supplier_StatesServiced")
   .WithParentKeyColumn("SupplierId")
   .WithChildKeyColumn("StateId");  
 }
}

Each mapping class configures the mapping for an entity within the constructor (um, ignore the evil calls to virtual methods in the constructors :-\). This looks much, much neater than the previously approaches, as Fluent NHibernate does most of the work for us. Let's check the configuration for our test:

private static ISessionFactory getSessionFactory() {
 var config = new Configuration();
 config.AddMappingsFromAssembly(Assembly.GetExecutingAssembly());
 return config.BuildSessionFactory();
}

Looks pretty good to me. :) But it gets better -- say I always name my identifiers in the form EntityNameId. If Fluent NHibernate knew that, then I could reduce my supplier class map to this:

public class SupplierMap : ClassMap<Supplier> {
 public SupplierMap() {                
  Id(x => x.SupplierId);
  Map(x => x.Name);
  HasManyToMany<State>(x => x.StatesServiced)
   .AsBag()
   .WithTableName("Supplier_StatesServiced");
 }
}

After all, we know the keys used to map suppliers and states are going to be SupplierId and StateId, so the many-to-many mapping becomes trivial. Fluent NHibernate currently assumes the names will in the form supplier_id, but that's no big deal, because it also let's me change the conventions used:

private static ISessionFactory getSessionFactory() {
 var config = new Configuration();
 var model = getFluentNhibernatePersistenceModel();
 model.Configure(config);            
 return config.BuildSessionFactory();
}

private static PersistenceModel getFluentNhibernatePersistenceModel() {
 var model = new PersistenceModel();
 model.Conventions.GetForeignKeyName = prop => prop.Name + "Id"; //By default assumes prop.Name + "_id"
 model.Conventions.GetForeignKeyNameOfParent = type => type.Name + "Id";
 model.addMappingsFromAssembly(Assembly.GetExecutingAssembly());
 return model;
}

Pretty neat, huh? You can imagine how trivial you could get the mappings if you set your conventions correctly.

There is work under way to make this even easier using AutoMap functionality, which will be used to auto-magically infer mappings for your entities. You can then customise any special cases (like the many-to-many relationship we have in this case -- it will probably assume the more common one-to-many case by default).

Tools not covered here

I also had a quick look at ActiveWriter, but couldn't get it working (failed when trying to save the model and generate the correct files. Possibly because I was using NH 2.0, more likely that I had no idea what I was doing with it :)). It provides a designer within Visual Studio that you can use to generate your mapping files and .NET entity classes. It has the usual drag-and-drop designer goodness -- dragging database tables onto the surface or using toolbox items to create classes and adjust the properties to map to tables etc. It is meant to work with both Castle ActiveRecord and NHibernate.

The reason I didn't persevere with trying to get it to work is that I am well and truly over designers. I hate mousing all over a design surface and repeatedly hunting for the property you want and then repeatedly setting it over multiple boxes. No matter how nice the designer, I always seem to end up cursing it once the demo has finished and I start using it for real work. Of course this may just be a reflection on my advanced age and grumpy demeanor - YMMV. :) Oh yeah, and get off my lawn! :P

There are a number of other tools mentioned in the NHibernate 1.2 docs, including hbm2net (generate classes from HBM), as well as generation tools like CodeSmith and MyGeneration, but most of these seem to focus on generating the C# classes or SQL scripts for creating the database schema from the .hbm.xml. I think I'd prefer to control my entity and database creation, and instead try and make the mapping itself easier.

Conclusion

Fluent NHibernate looks absolutely fantastic, but is still in very early stages of development. If you don't like living on the bleeding edge, then the standard .hbm.xml files really aren't that bad once you've set up a couple of them. The good thing is you can switch between all these mapping methods without changing anything but the ISessionFactory initialisation code, which only occurs in one place within your application. All these changes were made with a continuously green test light. :)

Getting both item and index during C# enumerations

2008-08-30T23:55:00.003+10:00

I recently got an interesting comment on an older post of mine about implementing a Python-like range() function in C#. The commenter posed a solution to the slight feeling of disappointment experienced when you have a foreach loop and then realise you need to access the loop index, forcing a conversion to a for loop or manually incrementing a counter. The solution ended up with a syntax like this:

//From this comment:
int[] a = new int[] { 1, 2, 3, 4, 5 };
foreach (int i in Range.Array(a)) {
  // do something with i or a[i]
}

Great concept! :) Let's take it a step further by drawing some more inspiration from Python. Here's a Python list comprehension that uses the enumerate() function to loop over tuples of both index and item:

>>> sampleList = ['a','b','c','d']
>>> [(index,item) for index, item in enumerate(sampleList)]
[(0, 'a'), (1, 'b'), (2, 'c'), (3, 'd')]

Or in a more C#-like format:

>>> for index, value in enumerate(sampleList):
     print(index, value)
 
(0, 'a')
(1, 'b')
(2, 'c')
(3, 'd')

Let's see how this could work in C#. As usual, I'll start with a test:

[Fact]
public void Can_enumerate_index_and_item() {
 String[] strings = {"a", "b", "c", "d"};
 int expectedIndex = 0;
 foreach (var tuple in Enumerate.Over(strings)) {
  Assert.Equal(expectedIndex, tuple.Index);
  Assert.Equal(strings[tuple.Index], tuple.Item);
  expectedIndex++;
 }           
}

To pass this we'll need a simple Tuple class (better versions available) and an Enumerate class (not entirely happy with the names, but we're just mucking around here). I'm going to violate YAGNI guidelines here and not restrict us to just arrays of Strings.

public class Tuple<T> {
 public int Index { get; private set; }
 public T Item { get; private set; }

 public Tuple(int index, T item) {
  Index = index;
  Item = item;
 }
}

public class Enumerate {
 public static IEnumerable<Tuple<T>> Over<T>(IEnumerable<T> items) {
  int index = 0;
  foreach (T item in items) {
   yield return new Tuple<T>(index++, item);
  }  
 }
}

Note added 2008-10-03: As a colleague of mine pointed out, this is a bit evil as it is implying foreach will return items in the same order as indexed. This isn't actually guaranteed at all, so you might get cases where the returned index isn't the actual index of an item.

The original test passes (along with a couple of others omitted for brevity), and we can now write a C# version of the Python enumerate() sample at the start of this post:

String[] strings = { "a", "b", "c", "d" };            
foreach (var tuple in Enumerate.Over(strings)) {
 Console.WriteLine(tuple.Index + ", " + tuple.Item);
}
/* Outputs:
0, a
1, b
2, c
3, d
*/

I'm fairly sure there's a better (LINQ-y?) way of doing this, but this is all my Googling and I can come up with right now. :)

Modifying the SQL generated by NHibernate

2008-08-26T16:56:00.003+10:00

Is it possible to modify the SQL generated by NHibernate? Yes:

public class BadInterceptor : EmptyInterceptor, IInterceptor {
 SqlString IInterceptor.OnPrepareStatement(SqlString sql) {
  return doHorribleThingsToSqlString(sql);            
 }
 private SqlString doHorribleThingsToSqlString(SqlString sql) { ... }
}

protected static readonly ISessionFactory SessionFactory = initialiseSessionFactory();
private static ISessionFactory initialiseSessionFactory() {
 var config = new Configuration();
 config.AddAssembly(Assembly.GetExecutingAssembly());
 config.SetInterceptor(new BadInterceptor());
 return config.BuildSessionFactory();
}

Now don't! :) Seriously, it's evil.

If anyone knows a nice way to get NHibernate to add some custom SQL as part of it's SQL generation process, rather than this brute-force approach, then please let me know. I was initially playing around with this code to add some calls to SQL Server's binary_checksum() function when loading and saving entities, and I'd be interested if this is possible to do in a reasonably robust way.

dave^2 = -1

ReSharper Live Template for Dependency Properties (C#)

Occasional trouble mocking generic methods

Scenario-based unit testing post in PDF format

Moving to scenario-based unit testing in .NET

A note on terminology

The example

Testcase class per class

What's wrong with this?

Testcase class per fixture?

Testcase class per scenario

Refactoring toward scenario-based tests

Issues with this approach

Duplication in setup methods

What goes into the base class?

Tests that apply to multiple scenarios

Using in conjunction with other organisational methods

Conclusion

Dynamic disappointment

If it walks and quacks like a duck, too bad!

Setting up Git difftool on Windows

Configuration tweaks

Using git difftool

Basic .NET builds using Rake

Prerequisites

Basic build and test run

Running our rake build

Explicitly test what you are trying to test

Too LINQy?

A LINQ implementation

A procedural implementation

Who's right?

Garden Race Pt 3: It's GUI time!

Project status and work for iteration 3

Where to start?

Rollin', rollin', rollin'

Whose turn is it anyway?

Where am I?

This time I'm playing to win!

The worst, most blatant misuse of WPF in history!!!1!

On what poor, pitiful, defenseless customers has my monstrosity been unleashed?

Testing a class for making asynchronous calls

A neater approach

Testing legacy code when simple threading's involved

Questioning the approach

Isolating the logging behaviour in GetEmployee()

An integration test for logging

Isolating our threading problem

Bringing logging and threading back together

Conclusion

Git-aware PowerShell prompt

Using the script

Setting the default prompt

Setting up diff and merge tools for Git on Windows

Setting up a diff tool

Setting up a merge tool

Time for a test drive

Conclusion

An introduction to the SOLID principles of OO design

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

SOLID principles as a whole

Conclusion

Recommended reading and listening

References

Happy 2nd Blogoversary

Some random statistics

Most visited posts

Posts I like but no one visited :)

Where to from here?

System.BadImageFormatException on 64-bit OS

Bookmarklet to get commit message for JIRA integration

Unusual formatting with test-first extension method abuse

Formatting arrays for acceptance tests

Starting test first

First refactoring

Completing our ToFixtureString() requirements

Using `git difftool`

Isolating the logging behaviour in `GetEmployee()`

Completing our `ToFixtureString()` requirements