“When writing a unit test”

into this:

When_writing_a_unit_test

And do it in a single keystroke. My dirty little secret? I am a bad typist, so I need little helpers like this.

The following video will walk you through installing the macro and binding it up to a keyboard shortcut. If you haven’t worked with Visual Studio macros before, this might help get there a bit faster.

MP4

And here is the macro itself.

Imports System

Imports EnvDTE

Imports EnvDTE80

Imports EnvDTE90

Imports EnvDTE90a

Imports EnvDTE100

Imports System.Diagnostics

Imports System.Windows.Forms

Imports System.Text.RegularExpressions

Public Module BddMethods

    Sub BoxcarTheCurrentLineOfCode()

        Dim description As String

        Dim regEx As Regex = New Regex("""([^""]+)""")

        If DTE.ActiveDocument Is Nothing Then Return

        Dim currentLine As TextSelection = GetCurrentLine()

        If (currentLine Is Nothing Or currentLine.Text.Length() < 1) Then Return

        Dim stringMatch As Match = regEx.Match(currentLine.Text)

        For Each stringMatch In regEx.Matches(currentLine.Text)

            currentLine.Text = currentLine.Text.Replace(stringMatch.Value, BoxcarAString(stringMatch.Value))

        Next

        currentLine.EndOfLine()

    End Sub

    Private Function BoxcarAString(ByVal textSegmentToChange As String) As String

        Dim segmentAfterTheChange As String = textSegmentToChange.Trim()

        segmentAfterTheChange = segmentAfterTheChange.Replace("""", "")

        segmentAfterTheChange = segmentAfterTheChange.Replace(" ", "_")

        Return segmentAfterTheChange

    End Function

    Private Function GetCurrentLine() As TextSelection

        Dim currentLine As TextSelection = DTE.ActiveDocument.Selection()

        currentLine.StartOfLine(vsStartOfLineOptions.vsStartOfLineOptionsFirstColumn)

        currentLine.EndOfLine(True)

        Return currentLine

    End Function

End Module

From my unscientific observation, developers either love or hate MSpec.  For those that hate MSpec, I wonder if it is the grammatical syntax or the lambda-expression style creating the aversion.  Some even expound MSpec as cryptic and cumbersome.  This seems to be a common complaint – one I hope to address in this post.

I find that those drawn to MSpec have experienced an evolution of testing/specification styles, influenced partially by the community and partially by frameworks they have used.  At the very least, this has been my experience as I have transitioned from xUnit frameworks.

Conventions of MSpec

I particularly like the conventions MSpec encourages using its four delegate types:

Establish:

• Provides setup (context) for the specification
• One per class (but not required)
• “Unlimited” per specification or inheritance chain
• Runs down the inheritance chain prior to the Because delegate

Because:

• The action/event being tested
• One per specification

It:

• An assertion (usually extension methods/fluent interfaces based on NUnit/xUnit Assert classes)
• “Unlimited” per specification/class
• Can be “hosted” in a Behavior class
• Runs after the Because
• Can be reused when placed in a Behavior class
• If body of delegate is missing, will mark as “Ignored” or “Not Implemented” in a test runner

Cleanup:

• Provides teardown for the specification
• One per class (but not required)
• “Unlimited” per specification or inheritance chain
• Runs up the inheritance chain after the It delegates are completed

MSpec also has one other delegate type (Behaves_like<T>) and several optional attributes available (Subject, Tag, Ignore, Behavior).  [Subject] provides additional information about the specification. [Tag] is similar to the [Category] attribute in NUnit.  [Ignore] is self-explanatory. [Behavior] marks a class made up entirely of assertions (It delegates).  Behaves_like<T> is a delegate type that can be included in a specification block taking the place of a set of assertions (It delegates).

NUnit – TestFixture-Per-Class

I have gone from using a TestFixture-Per-Class style to a behavior-driven/context-specification style.  I would like to use the standard HomeController, created in an ASP.NET MVC 1.0 project, as an example class to explore this evolution. 

In my TestFixture-Per-Class days, I may have tested the Index action as follows:

[TestFixture]
public class HomeControllerTests
{
    [Test]
    public void IndexActionTest()
    {
        var controller = new HomeController();
        var result = (ViewResult) controller.Index();
        Assert.AreEqual("Welcome to ASP.NET MVC!", result.ViewData["Message"]);
    }
}

I do like the simplicity of the code.  One line to set up the test, one to execute, and one to assert.  There is a little ceremony involved with marking the class and methods with the NUnit attributes.  With this simple test, it is easy to distinguish the setup code from the assertion; yet, a more complex test would make scanning the test more difficult.  Comments can help, but tend to just add noise.

NUnit – Arrange/Act/Assert

With the advent of BDD, I started naming my classes and expectations as inspired by BDD syntax.  I might have used the [SetUp] attribute or a base class to organize my test code in a style similar to the following:

[TestFixture]
public class when_I_go_to_the_home_page: AAA
{
    private HomeController _controller;
    private ViewResult _result;

    protected override void Arrange()
    {
        _controller = new HomeController();
    }
    protected override void Act()
    {
        _result = (ViewResult)_controller.Index();
    }

    [Test]
    public void then_the_welcome_message_should_be_displayed()
    {
        _result.ViewData["Message"].ShouldEqual("Welcome to ASP.NET MVC!");
    }
}

This actively separates out the different responsibilities of the test.  You can see where the setup code is, as well as the action being tested.  The assertion is the only line of code in the test method.  There is still ceremony involved with the attributes.  Plus, we have added a little more ceremony and noise with the Arrange() and Act() overrides.  This simple test does not necessarily need the parts split in this manner, but it would help with more complex scenarios.  Additionally, the assertion is using extension methods based on the NUnit Assert classes which provides a little more clarity to the assertion.

MSpec

Once started down the path of a behavior-driven (or context/specification) style, I started looking at frameworks devoted to that style.  MSpec is one of those frameworks.  Here is the Index action specification in MSpec:

public class when_I_go_to_the_home_page
{
    Establish context = () =>  _controller = new HomeController();
    Because of = () => _result = (ViewResult)_controller.Index();
    It should_display_the_welcome_message = () => _result.ViewData["Message"].ShouldEqual("Welcome to ASP.NET MVC!"); 

    static HomeController _controller;
    static ViewResult _result;
}

If you look closely, this specification is very similar to the first NUnit test.  However, there are no attributes to specify and the specification has a distinct functional separation.  The Establish/Because/It syntax is analogous to the Given/When/Then language used in user stories or Arrange/Act/Assert syntaxes used in the previous example.  In my opinion, this has less noise than the test using NUnit with an AAA base class – even while using the lambda delegate syntax.

MSpec – SpecificationFor<ClassUnderTest>

I often use a base class to handle some of my setup code. Using StructureMap and RhinoMocks, it generates and injects proxied dependencies for the given class.  In this example, I have no dependencies to wire up, but I think you can still see the benefits.

public class when_I_go_to_the_home_page : SpecificationFor<HomeController>
{
    Because of = () => _result = (ViewResult)ClassUnderTest.Index();
    It should_display_the_welcome_message = () => _result.ViewData["Message"].ShouldEqual("Welcome to ASP.NET MVC!"); 

    static ViewResult _result;
}

The Establish delegate is not needed in this specification, because I have wired up the class via the base class.  I feel this version is most clear and concise of all the examples, and neither cryptic nor cumbersome  If you are interested in the SpecificationFor<T> base class and the supporting components, check out my previous post. 

Looking to the Future

I hope that this post has shown that MSpec does not have to be cryptic, nor cumbersome.  If you considered it as such before, please take another critical look.

Given the evolving state of the craft, I am sure that my test/specification style will continue to gradually change.  I am sure that my framework of choice will eventually change as well, especially as each framework is extended and challenged by others.  Hopefully, you can be open to evolving your style as well.

My first thought was “Crap, this is going to be rough”.  Mainly I was still thinking of my time trying to test Code Behind in Asp.Net WebForms.  I had to smack myself a few times after I remembered that the Controller base class is an abstract type.  Reality is that a Controller doesn’t have to be any harder to test than any other service class.  It isn’t like inheriting from Page (Asp.Net WebForms).

Not that my code did not have some lingering issues.  Like: why did I have something in my Controller Action that would require testing in the first place?  I hate having much logic at all in my Actions.  Get input, send it off for processing (logic), go somewhere.   That should be about it – unless you have to go to different places depending on what is returned.  Now, I want some tests.

Anyway, now back to your regularly scheduled program.

Now guys, don’t look at me in that way, I mean it well …

What is spike code?

A spike solution is a very simple program to explore potential solutions. Well I like to add that I think a spike is relatively small, if it becomes very large I am wondering if we are not talking about prototyping instead? In my experience a spike is perhaps a days worth of coding, but then that it is rather much, more normal is an hour or two. Within this time there could be several attempts to get the desired result.

There is spike code and there is SPIKE code

Jeremy is talking about spike code to learn an API or something like that, in that case you don’t have a real use case that you need to solve so there I completely agree and it should be deleted as soon as you have learned what you needed to know (or perhaps checked-in into a special spike area). I would not really consider this writing spike code anyway.

Also code that is really hacked together and not following any good design principles, there adding tests afterwards would not give you anything, if at all possible. Just throw away that code and start over again.

Test Driven Spikes (TDS)

First of all sorry for another three letter acronym.

When I write a spike I almost always drive the execution of this code through tests, tests are dead easy to fire-of and they give you instant feedback. It is also very easy to have several tests next to each other exploring different angles or approaches. So while creating my spikes they are sort of driven by tests. And I use tests to verify that my spike code does what I expect from it. It has been a very long time ago that I created a console application to test or try-out some code.

But those are not spikes!

Well what is different here from actual Test Driven Development Design (can we just start calling TDD; Test Driven design?) is that I do take shortcuts, not all angles are covered correctly and my tests are not very descriptive and readable. So it is not production ready code. Also the actual code should be cleaned-up, different naming and removing the new keywords if they are any at all.

For example: I would write a specification (or test if you will) that dictates that I want such and so to happen when doing this and that. I do this from a fairly high level, so most likely not directly on the class that does the specific work, but it could be. Anyway while trying to get this to pass I run into a little problem. The solution is not very straightforward and I am stuck.

So for me that is when the spike begins, the existing test remains, but I ignore it for now. I probably create a similar test but now much closer to the actual problem itself. And from there I start playing with the code.

I would also try to take small subsets of the problem and try to fix that independently from the bigger problem area, again using tests. So when  have a few of these smaller subsets working I try to put them together. I refactor the code and tests to get my code working the way I need it to work.

When the spike goes bad I sometimes completely delete all the spike code and start over again, but more often I delete subsets of the spike and redo those. Then when I get the functionality that was needed in the initial specification I hook it up, and verify that it works.

When it does then I go back to the spike code and start cleaning it up as mentioned before, then I could also add some more tests for some edge cases, but more likely is that those edge cases would be discovered by sequential specifications, meaning actual use cases that are needed.

Also I am a bit weird

I am really bad at really hacking code together or I am just too stupid, but if I don’t clean-up after myself I lose the bigger picture or overview. Even in spikes, if I have the same code in a few places it annoys me, so I refactor it into a single method or into its own class. The same goes for naming, I don’t use variable names like a, b and c that makes no sense to me, also ReSharper makes it a no brainer anyway. Having unclean code just feels wrong to me.

Its the same with other things in my daily live, some stuff just needs to be true, like the car keys need to be on the desk. I can place them somewhere else, but next time I see it I move them to the right place. The volume knob in my car needs to be in a certain position, if it is not I use the volume on my steering wheel to adjust the knob without the volume. So yes I might have issues!

I think good design in spike code is important as well because it gives a better overview of what is going on, and if there is a place where you really need that then it is in code that you don’t really understand yet, i.e. spike code.

So in the end my spike code might actually get a much fine-grained test suite then the code that was not spiked. And this might actually make the test suite more brittle around this code, so it is not always a good thing, but for the time being I leave them where they are. Which is in a different place from the actual specifications so they are recognizable as spike tests.

From memory

Update: This paragraph came to me after having slept for the night.

I often hear that when deleting the spike code and starting over again you come-up with a much nicer solution then you finished with in the spike.

Now lets say you work like this and delete the whole spike code and started from scratch, don’t you think that the tests you will write are very much towards the already thought of solution? Can you really disconnect yourself from your previous attempt enough to come-up with better tests and potential better solution? I doubt it. Perhaps this will be true if you indeed really cut al corners, but even then the solution will be to close in memory.

Conclusion

So maybe we can conclude that I don’t know how to write spike code? Or that I am doing it all wrong? I would love to hear your opinions about this.

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.

I have the following base test fixture classes:

• BaseTestFixture
• BaseTestFixture<TSubjectUnderTest>
• AggregateRootTestFixture<TAggregateRoot>
• CommandTestFixture<TCommand, TCommandHandler, TAggregateRoot>
• EventTestFixture<TEvent, TEventHandler>
• PresenterTestFixture<TPresenter>

These different classes are all very specific towards a specific need, which is a direct opposite from what a framework usually provides.

Black box

I try my best to make my tests treat the subject under test (SUT) as a black box, meaning that in my tests I don’t directly interact with the actual class that I am testing. Instead I want to trigger the behavior by executing behavior that lies further outside. The behavior that triggers the behavior on the SUT may be an actual implementation, or it could be a fake.

The same applies to the result of the behavior that gets tested, instead of verifying some state in the SUT I want to verify what happens outside of the SUT. So what matters is that I test the behavior not the state of the subject under test.

I also try to get further away from the SUT then its immediate usage. Doing so makes the tests less brittle for change. This in itself is not always an easy task, but I recommend you try it anyway.

The BaseTestFixture

This is the simplest test fixture class that I have and I use this for and I actually don’t use this anywhere in the example code, but it serves a really good basic overview of the semantics that are shared among the other test fixture classes.

    1 namespace Test.Fohjin.DDD

    2 {

    3     [Specification]

    4     public abstract class BaseTestFixture

    5     {

    6         protected Exception CaughtException;

    7         protected virtual void Given() { }

    8         protected abstract void When();

    9         protected virtual void Finally() { }

   10 

   11         [Given]

   12         public void Setup()

   13         {

   14             CaughtException = new ThereWasNoExceptionButOneWasExpectedException();            

   15             Given();

   16 

   17             try

   18             {

   19                 When();

   20             }

   21             catch (Exception exception)

   22             {

   23                 CaughtException = exception;

   24             }

   25             finally

   26             {

   27                 Finally();

   28             }

   29         }

   30     }

   31 

   32     public class GivenAttribute : SetUpAttribute { }

   33 

   34     public class ThenAttribute : TestAttribute { }

   35 

   36     public class SpecificationAttribute : TestFixtureAttribute { }

   37 }

It is following the Given When Then (GWT) approach, and as you can see it is really simple. Also note that I introduced some other named attributes by simply inheriting from the default NUnit attributes, this was purely done to stay with the GWT approach.

Below here is an incredible KISS example of how you would use this BaseTestFixture, which I believe doesn’t need further explanation. (I know I am misusing the term KISS here, but I thought if was fitting anyway).

    1 namespace Test.Fohjin.DDD

    2 {

    3     public class Very_adding_a_number_to_the_subject_under_test : BaseTestFixture

    4     {

    5         private int SubjectUnderTest;

    6 

    7         protected override void Given()

    8         {

    9             SubjectUnderTest = 2;

   10         }

   11 

   12         protected override void When()

   13         {

   14             SubjectUnderTest += 2;

   15         }

   16 

   17         [Then]

   18         public void Then_the_new_value_of_the_subject_under_test_will_be_4()

   19         {

   20             SubjectUnderTest.WillBe(4);

   21         }

   22     }

   23 }

The BaseTestFixture<TSubjectUnderTest>

Now we are getting into a more interesting case because now my subject under test is actually provided by the generic parameter of the base test fixture class. And to be honest this class is only used with 12 specifications out of the 122 specification classes. This is mostly because it is still a very generic solution, but again a nice way to ease into it.

    1 namespace Test.Fohjin.DDD

    2 {

    3     [Specification]

    4     public abstract class BaseTestFixture<TSubjectUnderTest>

    5     {

    6         private Dictionary<Type, object> mocks;

    7 

    8         protected Dictionary<Type, object> DoNotMock;

    9         protected TSubjectUnderTest SubjectUnderTest;

   10         protected Exception CaughtException;

   11         protected virtual void SetupDependencies() { }

   12         protected virtual void Given() { }

   13         protected abstract void When();

   14         protected virtual void Finally() { }

   15 

   16         [Given]

   17         public void Setup()

   18         {

   19             mocks = new Dictionary<Type, object>();

   20             DoNotMock = new Dictionary<Type, object>();

   21             CaughtException = new ThereWasNoExceptionButOneWasExpectedException();

   22 

   23             BuildMocks();

   24             SetupDependencies();

   25             SubjectUnderTest = BuildSubjectUnderTest();

   26 

   27             Given();

   28 

   29             try

   30             {

   31                 When();

   32             }

   33             catch (Exception exception)

   34             {

   35                 CaughtException = exception;

   36             }

   37             finally

   38             {

   39                 Finally();

   40             }

   41         }

   42 

   43         public Mock<TType> OnDependency<TType>() where TType : class

   44         {

   45             return (Mock<TType>)mocks[typeof(TType)];

   46         }

   47 

   48         private TSubjectUnderTest BuildSubjectUnderTest()

   49         {

   50             var constructorInfo = typeof(TSubjectUnderTest).GetConstructors().First();

   51 

   52             var parameters = new List<object>();

   53             foreach (var mock in mocks)

   54             {

   55                 object theObject;

   56                 if (!DoNotMock.TryGetValue(mock.Key, out theObject))

   57                     theObject = ((Mock) mock.Value).Object;

   58 

   59                 parameters.Add(theObject);

   60             }

   61 

   62             return (TSubjectUnderTest)constructorInfo.Invoke(parameters.ToArray());

   63         }

   64 

   65         private void BuildMocks()

   66         {

   67             var constructorInfo = typeof(TSubjectUnderTest).GetConstructors().First();

   68 

   69             foreach (var parameter in constructorInfo.GetParameters())

   70             {

   71                 mocks.Add(parameter.ParameterType, CreateMock(parameter.ParameterType));

   72             }

   73         }

   74 

   75         private static object CreateMock(Type type)

   76         {

   77             var constructorInfo = typeof(Mock<>).MakeGenericType(type).GetConstructors().First();

   78             return constructorInfo.Invoke(new object[] { });

   79         }

   80     }

   81 }

Wow there is _a lot_ more going on here! You are right, because here I make the base test fixture responsible for instantiating the subject under test, including providing mocks for any dependencies that it may have. So it is an auto mocker as well, but the interesting part here is that it puts a reference of the injected mocks in a collection that you can access inside your tests by using the OnDependency<TType> method that returns a Moq object.

Take a look at a specification using this base test fixture class:

    1 namespace Test.Fohjin.DDD.Scenarios.Receiving_money_transfer

    2 {

    3     public class When_receiving_a_money_transfer : BaseTestFixture<MoneyReceiveService>

    4     {

    5         protected override void SetupDependencies()

    6         {

    7             OnDependency<IReportingRepository>()

    8                 .Setup(x => x.GetByExample<AccountReport>(It.IsAny<object>()))

    9                 .Returns(new List<AccountReport> { new AccountReport(Guid.NewGuid(), Guid.NewGuid(), "AccountName", "target account number") });

   10         }

   11 

   12         protected override void When()

   13         {

   14             SubjectUnderTest.Receive(new MoneyTransfer("source account number", "target account number", 123.45M));

   15         }

   16 

   17         [Then]

   18         public void Then_the_newly_created_account_will_be_saved()

   19         {

   20             OnDependency<IBus>().Verify(x => x.Publish(It.IsAny<ReceiveMoneyTransferCommand>()));

   21         }

   22     }

   23 }

So the first thing you see is the method SetupDependencies that is requesting the mock object for injected type IReporintgRepository and it is using the Moq way of setting up the Mock object. This is only needed when in your specification you need the mocks to be setup in a specific way. I intentionally separated the SetupDependencies from the Given as they may be two different things. And in the actual test you see the usage of the OnDependency method again where its being used to verify that something was indeed triggered on the injected class.

Now indeed this is not really treating the subject under test as a black box, for example in the When I make a direct call to a method on the subject under test. So my test knows about this now, meaning when it changes I need to change this test as well. So lets take a look where I go a bit further into the black box mentality.

The PresenterTestFixture<TPresenter>

Here I am not going to show you the code of the PresenterTestFixture implementation as it is almost identical the the previous base test fixture. So lets go straight to an actual specification:

    1 namespace Test.Fohjin.DDD.Scenarios.Adding_a_new_client

    2 {

    3     public class When_in_the_GUI_the_phone_number_of_the_new_client_is_saved : PresenterTestFixture<ClientDetailsPresenter>

    4     {

    5         private object CreateClientCommand;

    6 

    7         protected override void SetupDependencies()

    8         {

    9             OnDependency<IPopupPresenter>()

   10                 .Setup(x => x.CatchPossibleException(It.IsAny<Action>()))

   11                 .Callback<Action>(x => x());

   12 

   13             OnDependency<IBus>()

   14                 .Setup(x => x.Publish(It.IsAny<object>()))

   15                 .Callback<object>(x => CreateClientCommand = x);

   16         }

   17 

   18         protected override void Given()

   19         {

   20             Presenter.SetClient(null);

   21             Presenter.Display();

   22             On<IClientDetailsView>().ValueFor(x => x.ClientName).IsSetTo("New Client Name");

   23             On<IClientDetailsView>().FireEvent(x => x.OnFormElementGotChanged += null);

   24             On<IClientDetailsView>().FireEvent(x => x.OnSaveNewClientName += null);

   25 

   26             On<IClientDetailsView>().ValueFor(x => x.Street).IsSetTo("Street");

   27             On<IClientDetailsView>().ValueFor(x => x.StreetNumber).IsSetTo("123");

   28             On<IClientDetailsView>().ValueFor(x => x.PostalCode).IsSetTo("5000");

   29             On<IClientDetailsView>().ValueFor(x => x.City).IsSetTo("Bergen");

   30             On<IClientDetailsView>().FireEvent(x => x.OnFormElementGotChanged += null);

   31             On<IClientDetailsView>().FireEvent(x => x.OnSaveNewAddress += null);

   32 

   33             On<IClientDetailsView>().ValueFor(x => x.PhoneNumber).IsSetTo("1234567890");

   34             On<IClientDetailsView>().FireEvent(x => x.OnFormElementGotChanged += null);

   35         }

   36 

   37         protected override void When()

   38         {

   39             On<IClientDetailsView>().FireEvent(x => x.OnSaveNewPhoneNumber += null);

   40         }

   41 

   42         [Then]

   43         public void Then_the_save_button_will_be_disabled()

   44         {

   45             On<IClientDetailsView>().VerifyThat.Method(x => x.DisableSaveButton()).WasCalled();

   46         }

   47 

   48         [Then]

   49         public void Then_a_create_client_command_with_all_collected_information_will_be_published()

   50         {

   51             On<IBus>().VerifyThat.Method(x => x.Publish(It.IsAny<CreateClientCommand>())).WasCalled();

   52 

   53             CreateClientCommand.As<CreateClientCommand>().ClientName.WillBe("New Client Name");

   54             CreateClientCommand.As<CreateClientCommand>().Street.WillBe("Street");

   55             CreateClientCommand.As<CreateClientCommand>().StreetNumber.WillBe("123");

   56             CreateClientCommand.As<CreateClientCommand>().PostalCode.WillBe("5000");

   57             CreateClientCommand.As<CreateClientCommand>().City.WillBe("Bergen");

   58             CreateClientCommand.As<CreateClientCommand>().PhoneNumber.WillBe("1234567890");

   59         }

   60 

   61         [Then]

   62         public void Then_overview_panel_will_be_shown()

   63         {

   64             On<IClientDetailsView>().VerifyThat.Method(x => x.Close()).WasCalled();

   65         }

   66     }

   67 }

Again there is the setting up of a dependency in the beginning and then there is the Given method, Presenter in this case is the subject under test, so you can see that the specification still knows about the SUT in the Given, but you will notice that this is not used in either the When or the Then.

Hey what is that On thing in there? Well that is a very small DSL wrapping the Moq API. I did this to make it slightly more readable, and in this case it is very adapt towards working with a view and presenter. In the Given I am setting up my IClientDetailsView with the correct data, but I am also simulating that an event was triggered. This is not logic that the test is concerned about, all we do here is bring the view and the presenter in the correct state for this particular specification. So instead of setting these things directly on the presenter this will all be directed from the view.

Then in the When we again fire an event from the view, but in this case it is the going to trigger the behavior on the presenter that we want to verify. And in the Then methods we verify on the view again that the presenter actually did the correct things, but we also verify on other dependencies that the correct methods where called, in this case the IBus.

I am not completely happy with the mini DSL yet, but I think it is cleaner then the default Moq API. Just for those that are curious, here is the mini DSL which gets returned by the On method:

    1 namespace Test.Fohjin.DDD

    2 {

    3     public class MockDsl<TType> where TType : class

    4     {

    5         private readonly IDictionary<Type, object> _mocks;

    6 

    7         public MockDsl(IDictionary<Type, object> mocks)

    8         {

    9             _mocks = mocks;

   10         }

   11 

   12         public ValueSetter<TType, TProperty> ValueFor<TProperty>(Expression<Func<TType, TProperty>> selector)

   13         {

   14             return new ValueSetter<TType, TProperty>(_mocks, selector);

   15         }

   16 

   17         public void FireEvent(Action<TType> fieldSelector)

   18         {

   19             if (!_mocks.ContainsKey(typeof(TType)))

   20                 throw new Exception(string.Format("The requested dependency '{0}' is not specified in the constructor", typeof(TType).FullName));

   21 

   22             var mock = (Mock<TType>)_mocks[typeof(TType)];

   23             mock.Raise(fieldSelector);

   24         }

   25 

   26         public Verifier<TType> VerifyThat { get { return new Verifier<TType>(_mocks); } }

   27     }

   28 

   29     public class Verifier<TType> where TType : class

   30     {

   31         private readonly IDictionary<Type, object> _mocks;

   32 

   33         public Verifier(IDictionary<Type, object> mocks)

   34         {

   35             _mocks = mocks;

   36         }

   37 

   38         public void ValueIsSetFor(Action<TType> selector)

   39         {

   40             if (!_mocks.ContainsKey(typeof(TType)))

   41                 throw new Exception(string.Format("The requested dependency '{0}' is not specified in the constructor", typeof(TType).FullName));

   42 

   43             var mock = (Mock<TType>)_mocks[typeof(TType)];

   44             mock.VerifySet(selector);

   45         }

   46 

   47         public MethodVerifier<TType> Method(Expression<Action<TType>> selector)

   48         {

   49             return new MethodVerifier<TType>(_mocks, selector);

   50         }

   51     }

   52 

   53     public class MethodVerifier<TType> where TType : class

   54     {

   55         private readonly IDictionary<Type, object> _mocks;

   56         private readonly Expression<Action<TType>> _fieldSelector;

   57 

   58         public MethodVerifier(IDictionary<Type, object> mocks, Expression<Action<TType>> fieldSelector)

   59         {

   60             _mocks = mocks;

   61             _fieldSelector = fieldSelector;

   62         }

   63 

   64         public void WasCalled()

   65         {

   66             if (!_mocks.ContainsKey(typeof(TType)))

   67                 throw new Exception(string.Format("The requested dependency '{0}' is not specified in the constructor", typeof(TType).FullName));

   68 

   69             var mock = (Mock<TType>)_mocks[typeof(TType)];

   70             mock.Verify(_fieldSelector);

   71         }

   72     }

   73 

   74     public class ValueSetter<TType, TProperty> where TType : class

   75     {

   76         private readonly IDictionary<Type, object> _mocks;

   77         private readonly Expression<Func<TType, TProperty>> _fieldSelector;

   78 

   79         public ValueSetter(IDictionary<Type, object> mocks, Expression<Func<TType, TProperty>> fieldSelector)

   80         {

   81             _mocks = mocks;

   82             _fieldSelector = fieldSelector;

   83         }

   84 

   85         public void IsSetTo(TProperty value)

   86         {

   87             if (!_mocks.ContainsKey(typeof(TType)))

   88                 throw new Exception(string.Format("The requested dependency '{0}' is not specified in the constructor", typeof(TType).FullName));

   89 

   90             var mock = (Mock<TType>)_mocks[typeof(TType)];

   91             mock.SetupGet(_fieldSelector).Returns(value);

   92         }

   93     }

   94 }

CQRS and Event Sourcing

By combining CQRS and Event Sourcing we get an architecture that is very suitable for black box testing its behavior, which was a real eye opener when Greg demonstrated this to me. He says that the way to bring your aggregate root back into the desired state is to playback the events that are needed to do so. Then you can execute the behavior on the aggregate root, and finally to actually verify your behavior you retrieve the published events and verify that they are as expected.

Now the beauty of this is that the setup and the verification this will work on any aggregate root because we are using the IEventProvider interface there that they all implement. The only actual knowledge about the aggregate root that remains is the specific behavior that you trigger.

But I went a little bit further then what was shown during the course, I am saying that instead of executing the behavior on the aggregate root we could also just provide the command that should trigger this behavior to be executed. Because the command would be handled by a specific command handler which in turn would execute the domain behavior.

Now below here is the command test fixture that allows me to do just that, I need to provide the actual command, command handler and aggregate root types that are to be used in this specification.

    1 namespace Test.Fohjin.DDD

    2 {

    3     [Specification]

    4     public abstract class CommandTestFixture<TCommand, TCommandHandler, TAggregateRoot> 

    5         where TCommand : class, ICommand

    6         where TCommandHandler : class, ICommandHandler<TCommand>

    7         where TAggregateRoot : class, IOrginator, IEventProvider<IDomainEvent>, new()

    8     {

    9         private IDictionary<Type, object> mocks;

   10 

   11         protected TAggregateRoot AggregateRoot;

   12         protected ICommandHandler<TCommand> CommandHandler;

   13         protected Exception CaughtException;

   14         protected IEnumerable<IDomainEvent> PublishedEvents;

   15         protected virtual void SetupDependencies() { }

   16         protected virtual IEnumerable<IDomainEvent> Given() 

   17         {

   18             return new List<IDomainEvent>();

   19         }

   20         protected virtual void Finally() { }

   21         protected abstract TCommand When();

   22 

   23         [Given]

   24         public void Setup()

   25         {

   26             mocks = new Dictionary<Type, object>();

   27             CaughtException = new ThereWasNoExceptionButOneWasExpectedException();

   28             AggregateRoot = new TAggregateRoot();

   29             AggregateRoot.LoadFromHistory(Given());

   30 

   31             CommandHandler = BuildCommandHandler();

   32 

   33             SetupDependencies();

   34             try

   35             {

   36                 CommandHandler.Execute(When());

   37                 PublishedEvents = AggregateRoot.GetChanges();

   38             }

   39             catch (Exception exception)

   40             {

   41                 CaughtException = exception;

   42             }

   43             finally

   44             {

   45                 Finally();

   46             }

   47         }

   48 

   49         public Mock<TType> OnDependency<TType>() where TType : class

   50         {

   51             return (Mock<TType>)mocks[typeof(TType)];

   52         }

   53 

   54         private ICommandHandler<TCommand> BuildCommandHandler()

   55         {

   56             var constructorInfo = typeof(TCommandHandler).GetConstructors().First();

   57 

   58             foreach (var parameter in constructorInfo.GetParameters())

   59             {

   60                 if (parameter.ParameterType == typeof(IDomainRepository<IDomainEvent>))

   61                 {

   62                     var repositoryMock = new Mock<IDomainRepository<IDomainEvent>>();

   63                     repositoryMock.Setup(x => x.GetById<TAggregateRoot>(It.IsAny<Guid>())).Returns(AggregateRoot);

   64                     repositoryMock.Setup(x => x.Add(It.IsAny<TAggregateRoot>())).Callback<TAggregateRoot>(x => AggregateRoot = x);

   65                     mocks.Add(parameter.ParameterType, repositoryMock);

   66                     continue;

   67                 }

   68 

   69                 mocks.Add(parameter.ParameterType, CreateMock(parameter.ParameterType));

   70             }

   71 

   72             return (ICommandHandler<TCommand>)constructorInfo.Invoke(mocks.Values.Select(x => ((Mock) x).Object).ToArray());

   73         }

   74 

   75         private static object CreateMock(Type type)

   76         {

   77             var constructorInfo = typeof (Mock<>).MakeGenericType(type).GetConstructors().First();

   78             return constructorInfo.Invoke(new object[]{});

   79         }

   80     }

   81 

   82     public class ThereWasNoExceptionButOneWasExpectedException : Exception {}

   83 }

Please note that the Given method now returns an IEnumerable<IDomainEvent> this is to be used to provide the events that are needed to bring the aggregate root into the correct state for this specification. This is using the exact same mechanism as the actual code uses to make state changes in the aggregate root, so there cannot be a case that you are testing your aggregate root using a state that it cannot get into.

The When method returns the expected command, so all you do there is create the command with the correct information and return it to the specification.

Then in the try catch block you may have noticed that a command handler is executing the provided command and that after that the events are being retrieved from the aggregate root. These events are what you would verify to make sure your domain behavior is correct.

But this may all sound very abstract, lets look at a simple specification and see how clean and readable is really is:

    1 namespace Test.Fohjin.DDD.Scenarios.Withdrawing_cash

    2 {

    3     public class When_withdrawing_cash : CommandTestFixture<WithdrawlCashCommand, WithdrawlCashCommandHandler, ActiveAccount>

    4     {

    5         protected override IEnumerable<IDomainEvent> Given()

    6         {

    7             yield return new AccountOpenedEvent(Guid.NewGuid(), Guid.NewGuid(), "AccountName", "1234567890");

    8             yield return new CashDepositedEvent(20, 20);

    9         }

   10 

   11         protected override WithdrawlCashCommand When()

   12         {

   13             return new WithdrawlCashCommand(Guid.NewGuid(), 5);

   14         }

   15 

   16         [Then]

   17         public void Then_a_cash_withdrawn_event_will_be_published()

   18         {

   19             PublishedEvents.Last().WillBeOfType<CashWithdrawnEvent>();

   20         }

   21 

   22         [Then]

   23         public void Then_the_published_event_will_contain_the_amount_and_new_account_balance()

   24         {

   25             PublishedEvents.Last<CashWithdrawnEvent>().Balance.WillBe(15);

   26             PublishedEvents.Last<CashWithdrawnEvent>().Amount.WillBe(5);

   27         }

   28     }

   29 }

So you provide historical events to bring the aggregate root into the expected state, you fire of the command, then you verify the published events to ensure your domain behavior is correct. If you choose the correct naming for your events and commands, then a business person would be able to understand the specification. Especially if you parse the text and do a little bit of formatting.

Where is Should?

Hey what are all those WillBe and WillBeOfType things that I see in your specifications, should they not be ShouldBe and ShouldBeOfType? Well I used to think so as well, until I attended a presentation by Kevlin Henney at NDC where he explained that Should is not specific enough. Should indicates that it might not. I like to use the example; “I should really do the dishes, but I won’t”. By using Will Be and Must you are much more dictating what will or must happen, its not a question anymore.

Finally

I am completely taken by this approach and as you see you don’t need a big BDD framework for this. I think using something like this gives a good learning experience before going towards an actual BDD framework like MSpec. Also Uncle Bob just wrote a good post about to not abuse the Given When Then approach and also take a look at the Mocks aren’t Stubs article by Martin Fowler.

By now you must <grin> understand that I like to throw with code examples so yes the post is very long, but I hope it provides enough value instead of just confusion.

What is it? (Silverlight Testing Automation Tool)

StatLight is a tool developed for automating the setup, running, and gathering results of Silverlight unit tests. StatLight helps to speed up the feedback cycles while practicing TDD/BDD/(insert your test style here) during Silverlight development.

Where can I get StatLight?

http://StatLight.CodePlex.com

Happy Coding !!!

I have been using StructureMap.AutoMocking with MSpec (Machine.Specifications) and Rhino.Mocks for a few months now.  Although I am very comfortable with the patterns that emerge from using the frameworks together, introducing StructureMap.Automocking to other developers is sometimes challenging.

When viewing a specification or test set up with the Rhino.Mocks or Moq automocking container, what is being tested is not readily apparent.  Once the concept is explained and demonstrated, these same developers seem to have no issue with maintaining the specifications/tests.

I decided to wrap the details of the container to make the intention clearer and explanation easier.  I have started using this wrapper in my projects, and have found it makes building up specifications more efficient in my daily coding.

Let me know whether this is useful to you, or how it could be made more useful.

The Examples

Let’s contrive an example.  We’ll say we have a coffee machine that grinds its own beans before brewing. However, the hopper has to have beans before starting the grind.  Here is the basic specification:

We could start without a container, using Rhino.Mocks to build up the CoffeeMachine dependencies manually:

[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;
}

For those of you not familiar with the MSpec style, please refer to the following posts:

• 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;
}

Although I think this looks cleaner, the initialization of CoffeeMachine causes some confusion. Unfortunately, a common question would be, “Is RhinoAutoMocker<CoffeeMachine> creating a mocked version of CoffeeMachine?” Well, not exactly.

RhinoAutoMocker is an implementation of the AutoMocker base class which uses StructureMap to fill dependencies.  The RhinoAutoMocker implementation of the container uses Rhino.Mocks to generate all of dependencies of the target class, whereas the MoqAutoMocker implementation uses Moq.  (Optionally, the target class can be partially mocked in order to further isolate behavior.)  We then retrieve the class under test (in this case, CoffeeMachine) and its dependencies (IGrinder and IHopper) from the container for use.

If you do not need to setup any expectations in the specification, there is no need to retrieve the dependency from the container.  However, in this specification, we need both dependencies.

(Incidentally, I do not like the ClassUnderTest name.  I may end up changing this to Instance, ClassInstance, TargetClass, or something similar.  Suggestions?)

By moving the initialization of the RhinoAutoMocker to a base class, some of the chattiness of the context can be hidden.

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

I like to use Object Mothers in my test projects, especially when I have a large number of services or entities I need to feed into the things I am testing. For example, if I have a class I am testing that takes a constructor argument, I may set it up in my test like this:

   1: protected override void Arrange()

   2: {

   3:     _recipeController = new RecipeController(new RecipeEntity());

   4: }

Since I probably don’t want to pass in a real RecipeEntity I can obviously mock one. (Also, don’t freak over the fact that I am injecting a single entity into a controller. This isn’t the point of the post.)

   1: protected override void Arrange()

   2: {

   3:     Mock<IRecipeEntity> moqRm = new Mock<IRecipeEntity>();

   4:     _recipeController = new RecipeController(moqRm.Object);

   5: }

And this is all old hat goodness. It turns out that I find I want to mock IRecipeEntity a lot. And because of that, I can put it up in my context class OR I can get the mock through an object mother.

This is especially useful when I need to build up a complex set of dependencies. So without further delay, here is a mother implementation that mocks up a complete entity.

   1: public static class DomainEntityMother

   2:    {

   3:        public static IRecipeEntity Moq_IRecipeEntity()

   4:        {

   5:            Guid id = Guid.NewGuid();

   6:  

   7:            var moq = new Mock<IRecipeEntity>();

   8:                moq.SetupGet(m => m.Id).Returns(id);

   9:                moq.SetupGet(m => m.Title).Returns("Recipe : " + id);

  10:                moq.SetupGet(m => m.CooksNotes).Returns("Notes : " + id);

  11:                moq.SetupGet(m => m.Ingredients).Returns(DomainEntityMother.Moq_IIngredientEntities());

  12:  

  13:  

  14:            return moq.Object;

  15:        }

  16:  

  17:        public static IList<IIngredientEntity> Moq_IIngredientEntities()

  18:        {

  19:            var ingredientEntities = new List<IIngredientEntity>();

  20:                ingredientEntities.Add(Moq_IIngredientEntity());

  21:                ingredientEntities.Add(Moq_IIngredientEntity());

  22:                ingredientEntities.Add(Moq_IIngredientEntity());

  23:                ingredientEntities.Add(Moq_IIngredientEntity());

  24:  

  25:            return ingredientEntities;

  26:        }

  27:  

  28:        private static int ingredientCounter = 0;

  29:  

  30:        public static IIngredientEntity Moq_IIngredientEntity()

  31:        {

  32:            ingredientCounter++;

  33:            Guid id = Guid.NewGuid();

  34:            var moq = new Mock<IIngredientEntity>();

  35:            moq.SetupGet(m => m.Amount).Returns(ingredientCounter.ToString);

  36:            moq.SetupGet(m => m.Unit).Returns("TBSP");

  37:            moq.SetupGet(m => m.Description).Returns("Ingredient : " + id);

  38:            moq.SetupGet(m => m.Id).Returns(id);

  39:            return moq.Object;

  40:        }

  41:  

  42:        public static IList<IRecipeEntity> Moq_IRecipeEntities()

  43:        {

  44:            IList<IRecipeEntity> recipeEntities = new List<IRecipeEntity>();

  45:            for (int i = 0; i < 5; i++)

  46:            {

  47:                recipeEntities.Add(Moq_IRecipeEntity());

  48:            }

  49:            return recipeEntities;

  50:        }

  51:    }

And now my test reads like this:

   1: protected override void Arrange()

   2: {

   3:     _recipeController = new RecipeController(DomainEntityMother.Moq_IRecipeEntity());

   4: }

Now, this is cool, but what if I want to make a bad entity? One that should make my test fail, for instance? Do I need another mother? Nope, I just use the one the mother created, an mess with it a little.

   1: protected override void Arrange()

   2: {

   3:     var moqEntity = Mock.Get(DomainEntityMother.Moq_IRecipeEntity());

   4:         moqEntity.SetupGet(m => m.Id).Returns(Guid.Empty);

   5:     _recipeController = new RecipeController(moqEntity.Object);

   6: }

Now I can create all those boundary condition tests that SHOULD fail by starting with a good entity and then only changing the parts I want to cause to be invalid.