Programming  /  Testing June 25, 2010

I have a crush on MSpec

Ever since I first started experimenting with unit tests, TDD and BDD I’ve almost exclusively been using 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
    public void IndexActionReturnsViewResultWithDefaultViewName()
        LogoController controller = 
            new LogoController();
        var result = controller.Index();


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 looks like this:

1 passed, 0 failed, 0 skipped, took 0,58 seconds (xunit).


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:

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();


LogoController, when index action is invoked
» should return a ViewResult with default view name

1 passed, 0 failed, 0 skipped, took 0,50 seconds (MSpec).

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:

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.

Joel Abrahamsson

Joel Abrahamsson

I'm a passionate web developer and systems architect living in Stockholm, Sweden. I work as CTO for a large media site and enjoy developing with all technologies, especially .NET, Node.js, and ElasticSearch. Read more


comments powered by Disqus

More about Testing