If you’re a reader of this blog, you’ll know that I’m a big fan of Behaviour Driven Development and have been for about the last two years. My interest in this style of development began when I attended JP Boodhoo’s Nothin But .Net training course “bootcamp” in Vancouver back in the spring of 2008, where I was first introduced to proper test-first development and the benefits it gave. Ever since then, I’ve been working with JP’s home-rolled BDD library, which started out as bdddoc and bddunit and has evolved over time into it’s current incarnation as the developwithpassion.bdd library. Two years ago, there were not many (if any) mature BDD frameworks out there (especially for .Net), so I stuck with JP’s framework throughout whilst delivering projects for EMC Consulting.

I have recommended the developwithpassion libraries to colleagues and used them in examples in blog subjects – most recently my ASP.Net MVC Controllers and BDD series, however, I’ve always struggled a bit with it’s lack of “productisation”. This is no fault of JP – he very kindly and generously makes the source code for this framework available on github, but it’s still very much his tool and evolves only as and when he needs it to in supporting his training and consulting activities.

It also has a few barriers to entry – lack of ReSharper support for test running may be fine if you’re using the command line all the time, however, for some this would be a must have before adopting properly (although there is a “hack” to get support for TestDriven.Net). Also, it’s difficult to set up – and a lack of clear instructions makes this even harder to get going, especially for people who are out of their comfort zone when it comes to Rake. Finally, it depends on old versions of Rhino.Mocks and MBUnit which makes integrating into new projects sometimes awkward if you want to use the latest and greatest. So, whilst I owe JP a lot, it was always at the back of my mind that lowering the barrier to entry and providing a few more IDE integration features would not go amiss if this framework was to continue to be my BDD tool of choice in the future.

I’d increasingly been hearing and reading good things about Machine.Specifications (MSpec) from colleagues and the .Net community and when I finally got round to checking it out, I was really pleased to find that the things I found lacking in developwithpassion were implemented magnificently in MSpec. Also, the syntax was practically identical to the syntax I’d already been using. The ReSharper support is great – both in the way it parses the specs in the Unit Test Sessions window and allows you to draft out your specs and have them show up as not implemented.

However, I’d become increasingly dependent on the richness of the developwithpassion library – especially in it’s support for creating mock objects, automatically registering dependencies and using these to build up the system under test (the subject in MSpec terminology) – a kind of Auto Mocking framework baked right into the library.

With MSpec being more of a product – with support from a wider community, an easy installation, great IDE integration etc. this seemed the logical way to go and I began to realise that adding this extra richness of functionality to MSpec would make a brilliant tool.

So, I decided to create Machine.Specifications.AutoMocking to add in the missing pieces that I’d been using from developwithpassion – a base specification class to use in MSpec specifications providing the following functionality:

  1. An easy mechanism for creating and registering mock instances of the dependencies that the system under test requires (using RhinoMocks mocking framework).
  2. A easy mechanism for creating mock objects for use in specifications (initially using RhinoMocks mocking framework).
  3. Automatically creating and exposing an instance of system under test, with all registered dependencies, based on the specified interface (optional) and subject type.
  4. ReSharper File Templates for specifications for subjects with and without a contract.


The following example shows how a mock instance of INewsService can easily be created and registered for the NewsController. The base Specification class exposes the subject property, which is an instance of NewsController that has automatically been created using all the registered dependencies.

using Machine.Specifications;
using Machine.Specifications.AutoMocking.Rhino;
using Rhino.Mocks;

namespace Machine.Specifications.AutoMocking.Example.Rhino
    /// <summary>
    /// Example specification for a class without a contract that uses constructor based DI
    /// </summary>
    public abstract class context_for_news_controller : Specification<NewsController>
        protected static INewsService newsService;

        Establish context = () =>
            newsService = DependencyOf<INewsService>(); // DependencyOf creates and registers a mock instance of the dependency

    public class when_the_news_controller_is_told_to_display_the_default_view : context_for_news_controller
        static string result;

        Establish context = () => newsService.Stub(x => x.GetLatestHeadline()).Return("The latest headline");

        Because of = () => result = subject.Index(); // the subject has been created for us automatically, with all registered dependencies

        It should_ask_the_news_service_for_the_latest_headline =
            () => newsService.AssertWasCalled(x => x.GetLatestHeadline());

        It should_display_the_latest_headline = () => result.ShouldEqual("The latest headline");

What next?

This is still very much work in progress, but so far I’ve added all the features I needed to re-factor my recent BDD-MVC controllers example to use Machine.Specifications and Machine.Specifications.AutoMocking. I’ve added the project code to GitHub so please feel free to get it and take a look – and start to use it with your MSpec specifications!

I plan to provide support for other mock frameworks (e.g. Moq).

I held off finishing off my MVC Controller series by posting the source code as promised, as I wanted to see if I could switch to using MSpec before I went ahead with this. Now that I know I can, expect this full example to come soon – using all the goodness I’ve talked about in Machine.Specfications.AutoMocking


It goes without saying – but thanks to both Aaron Jensen and the Machine community and JP Boodhoo for building two great tools. All the real hard work had already been done by these guys.