The project started out a couple of years ago on Google code and was first initiated by James Avery. Contribution stopped at some point until recently where Svein Arne Ackenhausen forked the source code and put it on GitHub. Now it runs both for .NET as well as Mono, with NUnit, MSTest and xUnit as the currently supported unit test frameworks.

Here’s a screenshot from the feedback window when all tests pass:

And here you can see the same window after I broke one of my unit tests:

Here you can see which particular unit test has been broken and by clicking the specified link you end up at the right source file in Visual Studio.

I encourage you to pick up this small tool and learn how it can facilitate your TDD flow. Take a look at this page in order to get up-and-running in no time. Also don’t forget to provide the owner(s) of this project with some feedback that you might have. Svein has been very helpful over the last week answering all my stupid questions and remarks (and the Nobel price for this year’s most patient person goes to … ;-) ).

I would definitely like to see this tool becoming more popular, so go check it out.  

Something that is simple yet effective, delivered with grace.

Bringing the dead to life

Unit tests tell us why and how our code is effective

i = 5;  // Widget count defaults to five.

widgetCount = DEFAULT_WIDGET_COUNT;

1.1.5 When a new widget is created, the widget count should be increased by one.

public void When_NewWidgetIsCreated_Then_WidgetCountIsIncreasedByOne()
{
     WidgetFactory.Count = 3;
     WidgetFactory.CreateNew();
     assertEquals(4, WidgetFactory.Count);
}

What exactly are we replacing?

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Suppose we have to create some sort of specification that validates the format of an e-mail address. We typically use some regular expression in order to ensure that a specified e-mail address is properly formatted.

public class EmailSpecification
{
    private const String EmailRegexPattern = @".. SOME_REGEX_PATTERN ...";

    public Boolean IsSatisfiedBy(String candidate)
    {
        var regex = new Regex(EmailRegexPattern);
        return regex.IsMatch(candidate);
    }
}

I guess this is pretty common and straightforward. One way to provide some unit tests for this particular piece of code is to check a whole number of e-mail addresses that either pass or fail the specification. The following example shows only a couple of scenarios:

[TestFixture]
public class When_validating_an_email
    : ContextSpecification<EmailSpecification>
{
    protected override EmailSpecification Create_subject_under_test()
    {
        return new EmailSpecification();
    }

    [Test]
    public void ShouldBeSatisfied()
    {
        Assert.That(SUT.IsSatisfiedBy("one2@three.com"));
        Assert.That(SUT.IsSatisfiedBy("one@two3.com"));
    }

    [Test]
    public void ShouldNotBeSatisfied()
    {
        Assert.That(SUT.IsSatisfiedBy("one_two.com"), Is.False);
        Assert.That(SUT.IsSatisfiedBy("one_two@"), Is.False);
    }
}

A slightly more concise approach for these kind of unit tests can be accomplished by utilizing a feature of any decent unit test framework called row tests. With this approach we can, at the very least, reduce the number of asserts we have to write for each unit test. 

[TestFixture]
public class When_validating_an_email__approach_2
    : ContextSpecification<EmailSpecification>
{
    protected override EmailSpecification Create_subject_under_test()
    {
        return new EmailSpecification();
    }

    [RowTest]
    [Row("one2@three.com")]
    [Row("one@two3.com")]
    public void ShouldBeSatisfied(String email)
    {
        Assert.That(SUT.IsSatisfiedBy(email));
    }

    [RowTest]
    [Row("one_two.com")]
    [Row("one_two@")]
    public void ShouldNotBeSatisfied(String email)
    {
        Assert.That(SUT.IsSatisfiedBy(email), Is.False);
    }
}

Notice that I explicitly called both of these approaches unit tests as they don’t have much to do with BDD in my opinion. I’m not saying that using regular unit tests is a bad thing, but with  behavior-driven development context is king. So these unit tests are perfect examples of ‘context betrayal’ when following the BDD approach.

Lets see what MSpec can bring to the table for these kind of scenarios:

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_with_a_number_in_the_local_part
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one2@three.com";

    Behaves_like<SatisfiedSpecificationBehavior> a_satisfied_specification;
}

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_with_a_number_in_the_domain_name
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one@two3.com";

    Behaves_like<SatisfiedSpecificationBehavior> a_satisfied_specification;
}

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_without_an_At_sign
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one_two.com";

    Behaves_like<UnsatisfiedSpecificationBehavior> an_unsatisfied_specification;
}

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_without_a_domain
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one_two@";

    Behaves_like<UnsatisfiedSpecificationBehavior> an_unsatisfied_specification;
}

In order to escape ‘context betrayal’, we’ve split up every context into a separate context/specification. In order to reduce the amount of effort caused by duplicate code, we stripped the context setup to the bare minimum (just a particular e-mail address in this case). The observations are isolated into MSpec behaviors which provides a very readable description of their outcome. Lets take a look at what is needed in order to get these behaviors to work.

But first lets take at look at the abstract base class that we’ve used for the context/specifications we’ve just shown.

public abstract class email_specification_specs
{
    Establish context = () =>
    {
        SUT = new EmailSpecification();
    };

    Because of = () =>
        Result = SUT.IsSatisfiedBy(EmailAddress);

    protected static Boolean Result;
    protected static String EmailAddress { get; set; }
    protected static EmailSpecification SUT { get; set; }
}

We abstracted as much as possible into this base class in order to remove duplication in the context/specifications. The creation of the subject-under-test and the calling of its IsSatisfiedBy method, but the important one is the declaration of the Result field. This field contains the outcome of the IsSatisfiedBy method. Finally, lets have a look at the behaviors themselves:

[Behaviors]
public class SatisfiedSpecificationBehavior
{
    protected static Boolean Result;
    
    It should_satisfy_the_specification = () =>
        Result.ShouldBeTrue();
}

[Behaviors]
public class UnsatisfiedSpecificationBehavior
{
    protected static Boolean Result;

    It should_not_satisfy_the_specification = () =>
        Result.ShouldBeFalse();
}

In order to create an MSpec behavior, we just have to create a separate class that we decorate with the Behaviors attribute. Also notice that we have the same declaration of the Result field. MSpec ensures that this field gets initialized with the value of the other Result field that is set in the base class of the context/specifications. Note that you don’t necessarily need to put this field in a base class. You can have that field in every context/specification if you’d like (not sure why) as long as the names match with the fields used in the defined behaviors.

I personally like the way how the MSpec contributors tried to solve testing the same logic with different input patterns and the syntax they provided to back this up.  

We’ll use the same example as the one used in the previous post, but now we’ll deal with the message handler that makes a particular customer preferred.

//
// Subject under test
//
public class MakeCustomerPreferredMessageHandler
{
    private readonly ICustomerRepository<ICanMakeCustomerPreferred> _repository;

    public MakeCustomerPreferredMessageHandler(
        ICustomerRepository<ICanMakeCustomerPreferred> repository)
    {
        _repository = repository;
    }

    public void Handle(MakeCustomerPreferredMessage message)
    {
        var customer = _repository.Get(message.CustomerId);
        if(null == customer)
            throw new InvalidOperationException(
                "No customer for specified identifier");
        
        customer.MakePreferred();
        _repository.Save(customer);
    }
}

The Customer class implements a ‘role interface’ called ICanMakeCustomerPreferred. We retrieve a customer from the repository and make it preferred. We throw an exception in case the customer cannot be found in the data store.

Here are the context/specifications for this easy example:

[Subject("Making a customer preferred")]
public class when_making_a_customer_preferred
    : context_specification<MakeCustomerPreferredMessageHandler>
{
    Establish context = () =>
    {
        _message = new MakeCustomerPreferredMessage { CustomerId = 6412 };

        Repository.Stub(repository => repository.Get(_message.CustomerId))
            .Return(Customer);
    };

    Because of = () => 
        SUT.Handle(_message);
    
    It should_mark_the_customer_as_preferred = () =>
        Customer.AssertWasCalled(customer => customer.MakePreferred());

    It should_save_the_customer_in_the_repository = () =>
        Repository.AssertWasCalled(repository => repository.Save(Customer));

    private static ICanMakeCustomerPreferred Customer
    {
        get { return Dependency<ICanMakeCustomerPreferred>(); }
    }

    private static ICustomerRepository<ICanMakeCustomerPreferred> Repository
    {
        get { return Dependency<ICustomerRepository<ICanMakeCustomerPreferred>>(); }
    }

    private static MakeCustomerPreferredMessage _message;
}

[Subject("Making a customer preferred")]
public class when_making_an_unexisting_customer_preferred
    : context_specification<MakeCustomerPreferredMessageHandler>
{
    Establish context = () =>   
    {
        _message = new MakeCustomerPreferredMessage() { CustomerId = 61544 };

        Dependency<ICustomerRepository<ICanMakeCustomerPreferred>>()
            .Stub(repository => repository.Get(_message.CustomerId))
            .Return(null);
    };

    Because of = () =>
        _resultingException = Catch.Exception(() => SUT.Handle(_message));

    It should_result_in_an_error = () =>
        _resultingException.ShouldBeOfType<InvalidOperationException>();

    private static MakeCustomerPreferredMessage _message;
    private static Exception _resultingException;
}

I want to point out that all fields and properties are made static. This is needed so that the anonymous methods can access them. I’m also using a base class for these specifications which I’ll show next. This base class uses an auto mocking container for providing the requested mocks and stubs through the Dependency and Stub methods.

public abstract class context_specification<TSubjectUnderTest>
    where TSubjectUnderTest : class
{
    private static IAutoMockingContainer<TSubjectUnderTest> _autoMockingContainer;
    protected static TSubjectUnderTest SUT { get; set; }

    Establish context = () =>
    {
        _autoMockingContainer = new StructureMapAMC<TSubjectUnderTest>();
        SUT = _autoMockingContainer.Create();     
    };
    
    Cleanup stuff = () => 
    {
        SUT = null;
        _autoMockingContainer = null;
    };

    protected static TDependency Dependency<TDependency>()
        where TDependency : class
    {
        return _autoMockingContainer.GetMock<TDependency>();
    }

    protected static TStub Stub<TStub>()
        where TStub : class
    {
        return _autoMockingContainer.GetStub<TStub>();
    }
}

public interface IAutoMockingContainer<TSubject>
    where TSubject : class
{
    TSubject Create();
    TMock GetMock<TMock>() where TMock : class;
    TStub GetStub<TStub>() where TStub : class;
}

public class StructureMapAMC<TSubject> 
    : IAutoMockingContainer<TSubject>
    where TSubject : class
{
    private readonly RhinoAutoMocker<TSubject> _rhinoAutoMocker;

    public StructureMapAMC()
    {
        _rhinoAutoMocker = 
            new RhinoAutoMocker<TSubject>(MockMode.AAA);
    }

    public TSubject Create()
    {
        return _rhinoAutoMocker.ClassUnderTest;
    }

    public TMock GetMock<TMock>() 
        where TMock : class
    {
        return GetDependency<TMock>();
    }

    public TStub GetStub<TStub>() 
        where TStub : class
    {
        return GetDependency<TStub>();
    }

    private TDependency GetDependency<TDependency>() 
        where TDependency : class
    {
        return _rhinoAutoMocker.Get<TDependency>();
    }
}

Notice that I’m using the Establish and Cleanup delegates in the context_specification base class. This doesn’t prevent that these can be used again in derived context/specifications. MSpec ensures that the anonymous methods are called in the right order. This means that the Establish method of the base class is called before the Establish method of the derived context/specifications.    

Absolutely no rocket science here, but I figured it might come in handy when you need it. For the next post I’ll try to demonstrate how to deal with reusable behaviors.

[TestFixture]
public class When_making_a_regular_customer_preferred
    : ContextSpecification<Customer>
{
    protected override Customer Create_subject_under_test()
    {
        return new Customer(new[] { _order });
    }

    protected override void Establish_context()
    {
        _order = new Order(new[] { new OrderItem(12), 
                                   new OrderItem(16) });
                                   
        _totalAmountWithoutDiscount = _order.TotalAmount;
    }

    protected override void Because()
    {
        SUT.MakePreferred();
    }

    [Test]
    public void Then_the_customer_should_be_marked_as_preferred()
    {
        SUT.IsPreferred.ShouldBeTrue();
    }

    [Test]
    public void Then_a_ten_percent_discount_should_be_applied_to_all_outstanding_orders()
    {
        _order.TotalAmount.ShouldBeEqualTo(
            _totalAmountWithoutDiscount * 0.9);
    }

    private Order _order;
    private Double _totalAmountWithoutDiscount;
}

[TestFixture]
public class When_making_a_preferred_customer_preferred
    : ContextSpecification<Customer>
{
    protected override Customer Create_subject_under_test()
    {
        var customer = new Customer(new[] { _order });
        customer.MakePreferred();
        return customer;
    }

    protected override void Establish_context()
    {
        _order = new Order(new[] { new OrderItem(12), 
                                   new OrderItem(16) });
        _totalAmountWithoutDiscount = _order.TotalAmount;
    }

    protected override void Because()
    {
        SUT.MakePreferred();
    }

    [Test]
    public void Then_no_additional_discount_should_be_applied_to_the_outstanding_orders()
    {
        _order.TotalAmount.ShouldNotBeEqualTo(
            _totalAmountWithoutDiscount * 0.81);
    }

    private Order _order;
    private Double _totalAmountWithoutDiscount;
}

//
// Subject under test
//
public class Customer
{
    private readonly List<Order> _orders;
    public Boolean IsPreferred { get; private set; }

    public Customer(IEnumerable<Order> orders)
    {
        _orders = new List<Order>(orders);
    }

    public void MakePreferred()
    {
        if(IsPreferred)    
            return;
    
        IsPreferred = true;
        _orders.ForEach(order => order.ApplyDiscount(10));
    }
}

The bottom line of this example is that preferred customers get a 10 percent discount. Customers that are already preferred do not get an additional discount or otherwise we’re out of business ;-).

I’ve been pretty happy with this approach so far, although sometimes there were some quirks associated with this. So it was time for me to look beyond the horizon again, trying to look for ways to improve.

Machine.Specifications or MSpec for short is something that has been on my ‘cool-things-to-learn-list’ for quite some time now. As you will see later in this post, the syntax is a bit different as one would come to expect from a context/specification framework that targets the C# programming language. Its seems to be heavily inspired by Scott Bellware’s SpecUnit framework and RSpec.

Lets see how to set things up first.

The most obvious starting point is downloading the bits and bytes. You can grab the source code from GitHub and build it or you can wuss out like I did and get the latest build from the TeamCity.CodeBetter.com builder server (you can log on as a guest and search the artifacts for a latest build). 

When you’re heavily addicted to TestDriven.NET like I am, then its possible to keep using this wonderful Visual Studio add-in for running MSpec context/specifications. Just create a directory named Machine.Specifications in {$Program_Files}\TestDriven.NET 2.0 and copy the following files:

• Machine.Specifications.dll
• Machine.Specifications.TDNetRunner.dll
• InstallTDNetRunner.bat

Run the InstallTDNetRunner.bat file and you’re able to run all MSpec context/specifications using TestDriven.NET.

I also strongly encourage you to install the plugin for the Resharper test runner (if only to prevent some Resharper warnings later on). First step is to add a directory named Plugins to the Bin directory of Resharper ({$Program_Files}\JetBrains\ReSharper\v4.5\Bin\). Then create a directory named Machine.Specifications in the Plugins directory you just created and copy the following files:

• Machine.Specifications.dll
• Machine.Specifications.ReSharperRunner.4.5.dll
• InstallResharperRunner.4.5.bat

Run the InstallResharperRunner.4.5.bat file and you’re also able to run MSpec context/specifications using the Resharper test runner.

I’m not going to put this off any longer. Lets look at the code of the context/specifications shown earlier but completely revamped using the MSpec syntax:

[Subject("Making a customer preferred")]
public class when_a_regular_customer_is_made_preferred 
{
    Establish context = () =>
    {
        _order = new Order(new[] { new OrderItem(12), 
                                   new OrderItem(16) });
        _totalAmountWithoutDiscount = _order.TotalAmount;

        SUT = new Customer(new[] { _order });
    };

    Because of = () => 
        SUT.MakePreferred();

    It should_mark_the_customer_as_preferred = () =>
        SUT.IsPreferred.ShouldBeTrue();
        
    It should_apply_a_ten_percent_discount_to_all_outstanding_orders = () =>
        _order.TotalAmount.ShouldEqual(_totalAmountWithoutDiscount * 0.9);      

    private static Customer SUT;
    
    private static Order _order;
    private static Double _totalAmountWithoutDiscount;
}

[Subject("Making a customer preferred")]
public class when_a_preferred_customer_is_made_preferred
{
    Establish context = () =>
    {
        _order = new Order(new[] { new OrderItem(12), 
                                   new OrderItem(16) });
        _totalAmountWithoutDiscount = _order.TotalAmount;

        SUT = new Customer(new[] { _order });
        SUT.MakePreferred();
    };

    Because of = () =>
        SUT.MakePreferred();

    It should_apply_no_additional_discount_to_the_outstanding_orders = () => 
        _order.TotalAmount.ShouldNotEqual(_totalAmountWithoutDiscount * 0.81);

    private static Customer SUT;

    private static Order _order;
    private static Double _totalAmountWithoutDiscount;
}

I warned you about the syntax, didn’t I :-). It only took me a couple of seconds to get used to this syntax but now I’m completely hooked. Instead of using methods and attributes, MSpec utilizes delegates and anonymous methods. But there’s more.

When using NUnit for writing context/ specifications, the Establish_context and Because methods of the example shown earlier is executed before every observation (test). With MSpec, the Establish and Because anonymous methods are executed only once for every context no matter how many observations a particular context class contains. Big difference? Well, at first glance not but on second hand it does make selling out on the context a bit more difficult as it will probably blow up in your face sooner than later. You can force MSpec to execute the Establish and Because anonymous methods before every observation by applying the SetupForEachSpecification attribute to the context class, but I strongly encourage you to stay away from that unless absolutely needed.

Also notice that the fields in the contexts are now all static. This is needed so that the anonymous methods can access those.     

Running these context/specifications using TestDriven.NET yields the following output in the output window of Visual Studio:

Making a customer preferred, when a regular customer is made preferred
» should mark the customer as preferred
» should apply a ten percent discount to all outstanding orders

Making a customer preferred, when a preferred customer is made preferred
» should apply no additional discount to the outstanding orders

What’s not to like? Well, the only downside so far is that Resharper was giving me some warnings about classes and fields not being used etc. … . Many of those warnings disappeared by registering the MSpec plugin for the Resharper test runner as I explained earlier.

So far, so good. I’ve got two more posts coming up on MSpec, so stay tuned.

This post started to get a little long, so I won’t re-explain the concept.

Joshua Flanagan wrote a nice overview at his Los Techies blog: Auto mocking Explained.

My post is mainly here to describe the Unity version of an automocking container I threw together.

In Jan 2009 I blogged about my initial version of the Unity AutoMocker - Why am I blogging about it again?

I originally wrote the AutoMocker for the Unity container a year ago (Jan 2009, in Silverlight), and finally got around to placing the code up in the moq-contrib project in June of 2009.

I’m writing another post today in hopes to:

1. Get some feedback on how this little snippet of code should continue.
2. Give a little more how-to/example code
3. Describe some updates I made since I originally created it. 

Where can I get it?

This is one part where I’d appreciate some feedback.

I have two slightly different versions out there (currently).

I have one version at the ElegantCode repository where I was working on it, and the other I threw up at moq-contrib.

The core of the UnityAutoMockContainer is the same in both places, it’s how the tests are separated out that differ.

In the ElegantCode repository it’s an all in one self contained single file (that you can copy into your own test project(s)). You can then setup a single test in your own testing framework that runs all internal automocker tests (in case you need to modify it yourself, and don’t want to break any existing functionality). EX: test

[Test]
public void Should_run_all_UnityAutoMockContainer_internal_tests()
{
    Moq.AutoMocking.SelfTesting.UnityAutoMockContainerFixture
        .RunAllTests(Console.WriteLine);
}

I kind of like this format as it makes it easy to port between test libraries. Can’t say I like having the tests in the same file as the core, but it certainly is not a large chunk of code (so far) so it’s relatively small to maintain and definitely easier to manage as a single .cs file than another assembly (which would have to be version dependent on both Unity and Moq).

The moq-contrib is definitely where I think this helper should end up (and it is there). I just happened to break the tests out into the Silverlight test project and the core is alone in a file.

It’s current state isn’t as easy to copy to a test library (Silverlight/Desktop/Unity 1.2/Unity 2.0) as the one at ElegantCode. What does anyone think? Should I put them all together in one file?

However it ends up (1. all in one file or two (1 test) (1 core)) it will continue to be maintained on the moq-contrib project.

What is the high level API of the container?

It’s pretty simple, (currently) there are four methods on the container.

Two for registering items with the container. Say you want to register an already created instance, or say you want to map an interface to a concrete class and _not_ have the container generate mocks automatically for special cases.

And two for pulling items out of the container. Whether you want a instance of T or a Mock<T>, it gives you ways to retrieve both.

How can I setup my own registrations with the container?

Say I don’t want to have the container generate mocks for specific items and I want to supply specific configuration to the UnityContainer.

public UnityAutoMockContainer RegisterInstance<TService>(TService instance)

public UnityAutoMockContainer Register<TService, TImplementation>()
                where TImplementation : TService

Note: both of these registration methods return the container itself so you can fluently stack registration. EX:

AutoMockContainer
    .Register<IServiceA, ServiceA>()
    .Register<IServiceB, ServiceB>();

Let me know: I haven’t tested or played around with how this automocking container deals with any container specific xml configuration… So although I don’t think you should probably have that in a test assembly (stuff happens). Let me know if there are any issues.

How do I get items out of the container?

First is the Resolve<T>(). It will pull an item T out of the container. (Creating it if not already existing)

public T Resolve<T>()

When T is an interface Resolve<T> (unless you setup registration specifically with the container) should return basically “(new Mock<T>()).Object”

When T is a concrete Class, the container should return an instance of T and any of it’s dependencies will be satisfied by mocks. (Note that T will not be any sort of mocked instance of T, unless you used the GetMock<T> as described below first)

public Mock<T> GetMock<T>() where T : class

When T is an interface GetMock<T> should return basically “(new Mock<T>())”

When T is a concrete Class, the container should return a new Mock<T>() and any of it’s dependencies will be satisfied by mocks.

How do I use the UnityAutoMockContainer?

It’s pretty basic, you first create an instance of the UnityAutoMockContainer, and from there you can ask it for mocks of an (Interface, Class, or Abstract Class).

If you request an instance of a concrete class, or abstract class, the UnityAutoMockContainer will stuff mocks in for any constructor dependencies of your concrete class (if it can). You can then request from the container those same dependencies one at a time and either apply mocking setups or verifications.

NOTE: Anything the container creates will live as a singleton instance in the container. So any other requests from the container will always return the originally created instance. Therefore, each distinct scenario in a test suite should have their own instances of the container.

Below his an example of how you can leverage the container in some tests. Given this base fixture class…

public class FixtureBase
{
    private readonly UnityAutoMockContainer _autoMockContainer = new UnityAutoMockContainer();

    protected UnityAutoMockContainer AutoMockContainer
    {
        get { return _autoMockContainer; }
    }

    [TestFixtureSetUp]
    public void SetupContext_ALL()
    {
        Before_all_tests();
        Because();
    }

    [TestFixtureTearDown]
    public void TearDownContext_ALL()
    {
        After_all_tests();
    }

    protected virtual void Before_all_tests()
    {
    }

    protected virtual void Because()
    {
    }

    protected virtual void After_all_tests()
    {
    }
}

If I were given the following system to test.

public interface IServiceA { void RunA(); }
public interface IServiceB { void RunB(); }

public class TestComponent
{
    public TestComponent(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }

    public IServiceA ServiceA { get; private set; }
    public IServiceB ServiceB { get; private set; }

    public void RunAll()
    {
        if (!HowDidItGo())
            return;
        ServiceA.RunA();
        ServiceB.RunB();
    }

    public virtual bool HowDidItGo()
    {
        // some really nasty untestable code
        return true;
    }
}

The below example demonstrates simply verifying some behavior on the mocked dependencies of the system under test.

[TestFixture]
public class Example__how_to_pull_items_from_the_UnityAutoMockContainer_when_verifying_behavior_after_an_action_was_taken 
    : FixtureBase
{
    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        _testComponent = AutoMockContainer.Resolve<TestComponent>();
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Once());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Once());
    }
}

Next, you may have noticed that the system under test had a complicated internal method (that may not necessarily be testable). You can use the AutoMocker to create the system under test as a Mock itself, so we can override some of the behavior. Here’s how you could quickly do that.

Aside: I’m not saying this is a good practice or aids in good component design, just saying it’s possible

[TestFixture]
public class Example__how_to_use_the_UnityAutoMockContainer_to_override_a_method_on_the_SystemUnderTest_to_test_a_certain_behavior
    : FixtureBase
{

    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        var mockTestComponent = AutoMockContainer.GetMock<TestComponent>();

        mockTestComponent
            .Setup(s => s.HowDidItGo())
            .Returns(false);

        _testComponent = mockTestComponent.Object;
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Never());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Never());
    }
}

It’s amazing how much redundant test setup code this little helper has saved me in my tests. I hope others can find some use with this as well.

What is it? (Silverlight Testing Automation Tool)

Where can I get StatLight?

Happy Coding !!!

The Examples

[Subject(typeof(CoffeeMachine),"using vanilla Rhino.Mocks")]
public class Example01_when_preparing_coffee_grounds
{
    Establish context = () =>
        {
            Grinder = MockRepository.GenerateMock<IGrinder>();
            Hopper = MockRepository.GenerateMock<IHopper>();
            Hopper.Expect(x => x.HasBeans()).Return(true);
            CoffeeMachine = new CoffeeMachine(Grinder, Hopper);
        };

    Because of = () => _coffeeMachine.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

    static IGrinder Grinder;
    static IHopper Hopper;
    static CoffeeMachine CoffeeMachine;
}

• Make BDD Your BFF
• Step by Step to Using MSpec (Machine.Specifications) with ReSharper
• MSpec - Take 2
• MSpec BDD framework installer
• Updated! From the Morning Brew #487: BDD with MSpec and Rhino Auto Mocks, parts  1, 2, and 3 Here is the same specification using the RhinoAutoMocker<T> class provided by StructureMap.AutoMocking:

[Subject(typeof(CoffeeMachine),"using RhinoAutoMocker<CoffeeMachine>")]
public class Example02_when_preparing_coffee_grounds
{
    Establish context = () =>
        {
            CoffeeMachine = new RhinoAutoMocker<CoffeeMachine>();
            Grinder = CoffeeMachine.Get<IGrinder>();
            Hopper = CoffeeMachine.Get<IHopper>();
            Hopper.Expect(x => x.HasBeans()).Return(true);
        };

    Because of = () => v.ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

    static IGrinder Grinder;
    static IHopper Hopper;
    static RhinoAutoMocker<CoffeeMachine> CoffeeMachine;
}

[Subject(typeof(CoffeeMachine),"using RhinoAutoMocker base")]
public class Example03_when_preparing_coffee_grounds : with_rhinoautomocker
{
    Establish context = () => Hopper.Expect(x => x.HasBeans()).Return(true);

    Because of = () => CoffeeMachine.ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

}

[Subject("using RhinoAutoMocker<T>")]
public class with_rhinoautomocker
{
    protected static IGrinder Grinder;
    protected static IHopper Hopper;
    protected static RhinoAutoMocker<CoffeeMachine> CoffeeMachine;

    Establish context = () =>
    {
        CoffeeMachine = new RhinoAutoMocker<CoffeeMachine>();
        Grinder = CoffeeMachine.Get<IGrinder>();
        Hopper = CoffeeMachine.Get<IHopper>();
    };
}

However, we are still initializing and accessing the class in a less than optimal manner.To make the usage of the container a little more seamless, I decided to create a wrapper and factory for the AutoMocker.  Setup of the dependencies and expectations are done through an AutoMocker wrapper object.  The instance of the class under test is accessed through a ClassUnderTest object.

The Result

The specification (and base class) now look like this:

[Subject(typeof(CoffeeMachine),"using coffee machine base")]
public class Example05_when_preparing_coffee_grounds : with_coffee_machine
{
    Establish context = () => Hopper.Expect(x => x.HasBeans()).Return(true);

    Because of = () => ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));
}

[Subject("using SpecificationFor<CoffeeMachine>")]
public class with_coffee_machine : SpecificationFor<CoffeeMachine>
{
    protected static IGrinder Grinder;
    protected static IHopper Hopper;

    public with_coffee_machine
    {
        Grinder = AutoMocker.Get<IGrinder>();
        Hopper = AutoMocker.Get<IHopper>();
    }
}

As you can see, the base class inherits from SpecificationFor<T>.  The default constructor uses Rhino.Mocks(MockMode.AAA) to generate the dependencies.  It then exposes a AutoMocker object, which is just the wrapper around the AutoMocker base class.  It also exposes a ClassUnderTest object.  If I didn’t need to use the dependencies, I could make the Example05_when_preparing_coffee_grounds class inherit from SpecificationFor<CoffeeMachine> instead of inheriting from the base class.

The Code

I have included the code for the wrapper below for your review.  The code and six examples are available on my Google code repository. The repository also includes an example using the MoqAutoMocker.  All the examples have the same assertions, but are built up using the different techniques.

namespace CodeProgression.Framework.Testing
{
    public abstract class SpecificationFor<T> where T: class
    {
        protected static ClassUnderTest<T> Factory;

        // UPDATE 2009-12-21:
        //   Moved initialization here
        protected static T ClassUnderTest {get {return AutoMocker.Instance;} }

        protected SpecificationFor()
        {
            AutoMocker = AutoMockFactory.CreateTarget<T>();

            // UPDATE 2009-12-21:
            //    Initializing here prevented injected dependencies!
            // AutoMocker.PartialMockTheClassUnderTest();
            // ClassUnderTest = AutoMocker.Instance;
        }

        protected SpecificationFor(AutoMockType type)
        {
            AutoMocker = AutoMockFactory.CreateTarget<T>(type);

            // UPDATE 2009-12-21:
            // Initializing here prevented injected dependencies!
            // AutoMocker.PartialMockTheClassUnderTest();
            // ClassUnderTest = AutoMocker.Instance;
        }
    }

    public static class AutoMockFactory
    {
        public static ClassUnderTest<TARGETCLASS> CreateTarget<TARGETCLASS>() where TARGETCLASS : class
        {
            return CreateTarget<TARGETCLASS>(AutoMockType.RhinoMocksAAA);
        }

        public static ClassUnderTest<TARGETCLASS> CreateTarget<TARGETCLASS>(AutoMockType framework) where TARGETCLASS : class
        {
            AutoMocker<TARGETCLASS> mocker;
            ServiceLocator serviceLocator;
            switch (framework)
            {
                case AutoMockType.RhinoMocksAAA:
                    mocker = new RhinoAutoMocker<TARGETCLASS>(MockMode.AAA);
                    serviceLocator = new RhinoMocksAAAServiceLocator();
                    break;
                case AutoMockType.RhinoMocksClassic:
                    mocker = new RhinoAutoMocker<TARGETCLASS>(MockMode.RecordAndReplay);
                    serviceLocator = new RhinoMocksClassicServiceLocator();
                    break;
                case AutoMockType.Moq:
                    mocker = new MoqAutoMocker<TARGETCLASS>();
                    serviceLocator = new MoqServiceLocator();
                    break;
                default:
                    throw new ArgumentOutOfRangeException("framework");
            }
            return new ClassUnderTest<TARGETCLASS>(mocker, serviceLocator);
        }
    }

    public enum AutoMockType
    {
        Moq,
        RhinoMocksAAA,
        RhinoMocksClassic
    }

    public class ClassUnderTest<TARGETCLASS> where TARGETCLASS : class
    {
        readonly IAutoMocker<TARGETCLASS> _mocker;
        readonly ServiceLocator _serviceLocator;

        public ClassUnderTest(IAutoMocker<TARGETCLASS> mocker, ServiceLocator serviceLocator)
        {
            _mocker = mocker;
            _serviceLocator = serviceLocator;
        }

        public AutoMockedContainer Container
        {
            get { return _mocker.Container; }
        }

        public TARGETCLASS Instance
        {
            get { return _mocker.ClassUnderTest; }
        }

        public void MockObjectFactory()
        {
            _mocker.MockObjectFactory();
        }

        public void PartialMockTheClassUnderTest()
        {
            _mocker.PartialMockTheClassUnderTest();
        }

        public T Get<T>() where T : class
        {
            return _mocker.Get<T>();
        }

        public void Inject(Type pluginType, object stub)
        {
            _mocker.Inject(pluginType, stub);
        }

        public void Inject<T>(T target)
        {
            _mocker.Inject(target);
        }

        public T AddAdditionalMockFor<T>() where T : class
        {
            return _mocker.AddAdditionalMockFor<T>();
        }

        public void UseConcreteClassFor<T>()
        {
            _mocker.UseConcreteClassFor<T>();
        }

        public T[] CreateMockArrayFor<T>(int count) where T : class
        {
            return _mocker.CreateMockArrayFor<T>(count);
        }

        public void InjectArray<T>(T[] stubs)
        {
            _mocker.InjectArray(stubs);
        }

        public T Mock<T>() where T : class
        {
            return _serviceLocator.Service<T>();
        }
        public object Mock(Type serviceType)
        {
            return _serviceLocator.Service(serviceType);
        }
        public T PartialMock<T>() where T : class
        {
            return _serviceLocator.PartialMock<T>();
        }
    }
}

FYI: I’m very new to PowerShell, so any suggestions on how I implemented the below are welcome…

Examples of end result ShouldLookLike()…

Step 1: Figure out how to write a C# style extension method in PowerShell.

I found a great blog post describing how to extend any PowerShell object to add extension methods. Extension Methods in Windows PowerShell

<?xml version="1.0" encoding="utf-16"?>
<Types>
    <Type>
        <Name>System.Object</Name>
        <Members>
            <ScriptMethod>
                <Name>ShouldBeFalse</Name>
                <Script>
                    [NUnit.Framework.Assert]::IsFalse($this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldBeTrue</Name>
                <Script>
                    [NUnit.Framework.Assert]::IsTrue($this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldEqual</Name>
                <Script>
                    [NUnit.Framework.Assert]::AreEqual($args[0], $this)
                </Script>
            </ScriptMethod>
            <ScriptMethod>
                <Name>ShouldNotEqual</Name>
                <Script>
                    [NUnit.Framework.Assert]::AreNotEqual($args[0], $this)
                </Script>
            </ScriptMethod>
        </Members>
    </Type>
</Types>

NOTE: the file HAS to be saved with the extension .ps1xml Ex: NunitSpecificationPowerShellExtensions.ps1xml

Step 2: Load the extended type definition into the PowerShell runtime.

Update-TypeData -PrependPath NunitSpecificationPowerShellExtensions.ps1xml

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\NUnit 2.5.2\bin\net-2.0\framework\nunit.framework.dll") | Out-Null

#
# Update-TypeData -prependPath C:\Code\NunitSpecificationPowerShellExtensions.ps1xml
#

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\NUnit 2.5.2\bin\net-2.0\framework\nunit.framework.dll") | Out-Null

$true.ShouldBeTrue()

$false.ShouldBeFalse()

"a".ShouldEqual("a")

"a".ShouldNotEqual("b")

This post started to get a little long, so I won’t re-explain the concept.

Joshua Flanagan wrote a nice overview at his Los Techies blog: Auto mocking Explained.

My post is mainly here to describe the Unity version of an automocking container I threw together.

In Jan 2009 I blogged about my initial version of the Unity AutoMocker - Why am I blogging about it again?

I originally wrote the AutoMocker for the Unity container a year ago (Jan 2009, in Silverlight), and finally got around to placing the code up in the moq-contrib project in June of 2009.

I’m writing another post today in hopes to:

1. Get some feedback on how this little snippet of code should continue.
2. Give a little more how-to/example code
3. Describe some updates I made since I originally created it. 

Where can I get it?

This is one part where I’d appreciate some feedback.

I have two slightly different versions out there (currently).

I have one version at the ElegantCode repository where I was working on it, and the other I threw up at moq-contrib.

The core of the UnityAutoMockContainer is the same in both places, it’s how the tests are separated out that differ.

In the ElegantCode repository it’s an all in one self contained single file (that you can copy into your own test project(s)). You can then setup a single test in your own testing framework that runs all internal automocker tests (in case you need to modify it yourself, and don’t want to break any existing functionality). EX: test

[Test]
public void Should_run_all_UnityAutoMockContainer_internal_tests()
{
    Moq.AutoMocking.SelfTesting.UnityAutoMockContainerFixture
        .RunAllTests(Console.WriteLine);
}

I kind of like this format as it makes it easy to port between test libraries. Can’t say I like having the tests in the same file as the core, but it certainly is not a large chunk of code (so far) so it’s relatively small to maintain and definitely easier to manage as a single .cs file than another assembly (which would have to be version dependent on both Unity and Moq).

The moq-contrib is definitely where I think this helper should end up (and it is there). I just happened to break the tests out into the Silverlight test project and the core is alone in a file.

It’s current state isn’t as easy to copy to a test library (Silverlight/Desktop/Unity 1.2/Unity 2.0) as the one at ElegantCode. What does anyone think? Should I put them all together in one file?

However it ends up (1. all in one file or two (1 test) (1 core)) it will continue to be maintained on the moq-contrib project.

What is the high level API of the container?

It’s pretty simple, (currently) there are four methods on the container.

Two for registering items with the container. Say you want to register an already created instance, or say you want to map an interface to a concrete class and _not_ have the container generate mocks automatically for special cases.

And two for pulling items out of the container. Whether you want a instance of T or a Mock<T>, it gives you ways to retrieve both.

How can I setup my own registrations with the container?

Say I don’t want to have the container generate mocks for specific items and I want to supply specific configuration to the UnityContainer.

public UnityAutoMockContainer RegisterInstance<TService>(TService instance)

public UnityAutoMockContainer Register<TService, TImplementation>()
                where TImplementation : TService

Note: both of these registration methods return the container itself so you can fluently stack registration. EX:

AutoMockContainer
    .Register<IServiceA, ServiceA>()
    .Register<IServiceB, ServiceB>();

Let me know: I haven’t tested or played around with how this automocking container deals with any container specific xml configuration… So although I don’t think you should probably have that in a test assembly (stuff happens). Let me know if there are any issues.

How do I get items out of the container?

First is the Resolve<T>(). It will pull an item T out of the container. (Creating it if not already existing)

public T Resolve<T>()

When T is an interface Resolve<T> (unless you setup registration specifically with the container) should return basically “(new Mock<T>()).Object”

When T is a concrete Class, the container should return an instance of T and any of it’s dependencies will be satisfied by mocks. (Note that T will not be any sort of mocked instance of T, unless you used the GetMock<T> as described below first)

public Mock<T> GetMock<T>() where T : class

When T is an interface GetMock<T> should return basically “(new Mock<T>())”

When T is a concrete Class, the container should return a new Mock<T>() and any of it’s dependencies will be satisfied by mocks.

How do I use the UnityAutoMockContainer?

It’s pretty basic, you first create an instance of the UnityAutoMockContainer, and from there you can ask it for mocks of an (Interface, Class, or Abstract Class).

If you request an instance of a concrete class, or abstract class, the UnityAutoMockContainer will stuff mocks in for any constructor dependencies of your concrete class (if it can). You can then request from the container those same dependencies one at a time and either apply mocking setups or verifications.

NOTE: Anything the container creates will live as a singleton instance in the container. So any other requests from the container will always return the originally created instance. Therefore, each distinct scenario in a test suite should have their own instances of the container.

Below his an example of how you can leverage the container in some tests. Given this base fixture class…

public class FixtureBase
{
    private readonly UnityAutoMockContainer _autoMockContainer = new UnityAutoMockContainer();

    protected UnityAutoMockContainer AutoMockContainer
    {
        get { return _autoMockContainer; }
    }

    [TestFixtureSetUp]
    public void SetupContext_ALL()
    {
        Before_all_tests();
        Because();
    }

    [TestFixtureTearDown]
    public void TearDownContext_ALL()
    {
        After_all_tests();
    }

    protected virtual void Before_all_tests()
    {
    }

    protected virtual void Because()
    {
    }

    protected virtual void After_all_tests()
    {
    }
}

If I were given the following system to test.

public interface IServiceA { void RunA(); }
public interface IServiceB { void RunB(); }

public class TestComponent
{
    public TestComponent(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }

    public IServiceA ServiceA { get; private set; }
    public IServiceB ServiceB { get; private set; }

    public void RunAll()
    {
        if (!HowDidItGo())
            return;
        ServiceA.RunA();
        ServiceB.RunB();
    }

    public virtual bool HowDidItGo()
    {
        // some really nasty untestable code
        return true;
    }
}

The below example demonstrates simply verifying some behavior on the mocked dependencies of the system under test.

[TestFixture]
public class Example__how_to_pull_items_from_the_UnityAutoMockContainer_when_verifying_behavior_after_an_action_was_taken 
    : FixtureBase
{
    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        _testComponent = AutoMockContainer.Resolve<TestComponent>();
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Once());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Once());
    }
}

Next, you may have noticed that the system under test had a complicated internal method (that may not necessarily be testable). You can use the AutoMocker to create the system under test as a Mock itself, so we can override some of the behavior. Here’s how you could quickly do that.

Aside: I’m not saying this is a good practice or aids in good component design, just saying it’s possible

[TestFixture]
public class Example__how_to_use_the_UnityAutoMockContainer_to_override_a_method_on_the_SystemUnderTest_to_test_a_certain_behavior
    : FixtureBase
{

    private TestComponent _testComponent;

    protected override void Before_all_tests()
    {
        base.Before_all_tests();
        var mockTestComponent = AutoMockContainer.GetMock<TestComponent>();

        mockTestComponent
            .Setup(s => s.HowDidItGo())
            .Returns(false);

        _testComponent = mockTestComponent.Object;
    }

    protected override void Because()
    {
        _testComponent.RunAll();
    }

    [Test]
    public void Should_run_ServiceA_RunA()
    {
        AutoMockContainer
            .GetMock<IServiceA>()
            .Verify(v => v.RunA(), Times.Never());
    }

    [Test]
    public void Should_run_ServiceB_RunB()
    {
        AutoMockContainer
            .GetMock<IServiceB>()
            .Verify(v => v.RunB(), Times.Never());
    }
}

It’s amazing how much redundant test setup code this little helper has saved me in my tests. I hope others can find some use with this as well.