Ever since I first started experimenting with unit tests, TDD and BDD I’ve almost exclusively been using xUnit.net. For the most part I’ve been very happy with it. I like that it’s syntax is more adapted to TDD than NUnit’s and MBUnits and it contains most, if not all, features of MBUnit. One thing has bothered me though, and that is that I’m never a hundred percent happy with the expressiveness of my tests. That is I want someone, often myself, who reads my tests to have a clear understanding of their context and of what they test. I also want the output from running my test to communicate what has been tested and more importantly what, with fine granularity, failed.

A typical test that I write can look like this:

public class LogoControllerFacts
{
    [Fact]
    public void IndexActionReturnsViewResultWithDefaultViewName()
    {
        LogoController controller = 
            new LogoController();
            
        var result = controller.Index();

        Assert.Empty(result.ViewName);
    }
}

I’m not always writing tests that check trivial things like that an action on a ASP.NET MVC controller returns the default view name (that the view name is empty) but it seemed like a simple example to use.

When I run this test using TestDriven.NET the output from xUnit.net looks like this:

Machine.Specifications (or MSpec)

MSpec is an open source BDD framework founded by Aaron Jensen.

Rewritten to use MSpec the code for the same test will instead look like this:

[Subject(typeof(LogoController))]  
public class when_index_action_is_invoked
{
    static LogoController controller;

    Establish context = 
        () =>
            {
                controller = new LogoController();
            };

    It should_return_a_ViewResult_with_default_view_name = () =>
    {
        var result = controller.Index();

        result.ViewName.ShouldBeEmpty();
    };
}

As you can see syntax, while odd looking at first, is much more expressive. What I particularly like though is the output which is actually of a specification of how the system under test works. Therefore, if I haven’t used the component that I’m testing our touched the tests in a while I can just run the tests and quickly get up to speed by reading the output.

Just a fling?

Will the initial romance last and evolve into real love or is it just a temporary crush? We’ll have to see. At the moment I’m trying MSpec out in a project at work as well as on some open source projects on my spare time and at the moment I can’t see my self going back. But one never knows and using a BDD framework will probably come with it’s own challenges.

If/once I get more experienced using MSpec I’ll try to put together an introduction to it in another blog post, meanwhile here are some great resources:

• MSpec on GitHub (scroll down to “Getting started with MSpec” to find links to the latest builds)
• Introducing Machine.Specifications by Aaron Jensen
• How to MSpec by Byron Sommardahl (a collection of links to other resources)
• Stapplande steg med MSpec by Anders Jönsson (in Swedish)
• MSpec is Fantastic by Eric Lee (similar to this post, a quick note about how good MSpec is)

PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.