Why is it important?

The patterns and practices outlined in this book will help you develop more successful software solutions.

How?

Eric Evans shows how you can improve communication with your customer (by doing things like developing a ubiquitous language), implement agile practices and create maintainable solutions which follow good software development principles.

One of common criticisms of the book is that ‘it does go on a bit’.

The good news is that the folks over at InfoQ have come up with ‘Domain Driven Design Quickly’ which summarizes what Domain Driven Design is about.

The even better news is that it’s FREE if you register with InfoQ, which is no bad thing because it’s a fantastic resource with videos, presentations and some very good articles.

For an introduction to RhinoMocks check out How to write better unit tests using RhinoMocks and stubs.

You might fix the problem by passing in null or writing a line such as the one below

var somethingYouWantToStub = MockRepository.Stub<AnInterface>();

and it to the ever growing lines of creating stub objects.

Anouncer: What if there was a way to write your unit tests where you didn’t have to manually stub out everything up front and existing tests could still run if a constructor changes? Well there is!
Action: Automocking container enters from stage door left.

The code below shows two unit tests for a full name creator which calls various providers to get a first and last name and then concatenates together. Look out for:

• how in the first test (“Can_Create_FullName”) each name provider has to be stubbed out and then added in the constructor for the FullName creator.

• how in the second test (“Can_Create_FullName_Using_AutoMockingContainer”) an auto mocking container is used to create the FullName creator.
• The use of the arrange, act and assert to make the tests easier to follow

using System;
using NUnit.Framework;
using Rhino.Mocks;

namespace AutoMockingContainer
{
    public interface IFirstNameProvider
    {
        string GetFirstName();
    }

    public interface ILastNameProvider
    {
        string GetLastName();
    }

    public class FullNameCreator
    {
        private readonly IFirstNameProvider _firstNameProvider;
        private readonly ILastNameProvider _lastNameProvider;

        public FullNameCreator(IFirstNameProvider firstNameProvider, ILastNameProvider lastNameProvider)
        {
            _firstNameProvider = firstNameProvider;
            _lastNameProvider = lastNameProvider;
        }

        public string Concatenate()
        {
            var firstName = _firstNameProvider.GetFirstName(); ;
            var lastName = _lastNameProvider.GetLastName();
            return String.Format("{0} {1}", firstName, lastName);
        }
    }

    [TestFixture]
    public class FullNameCreatorTests
    {
        [Test]
        public void Can_Create_FullName()
        {
            // Arrange
            var firstNameProvider = MockRepository.GenerateStub<IFirstNameProvider>();
            var lastNameProvider = MockRepository.GenerateStub<ILastNameProvider>();

            FullNameCreator fullNameCreator = new FullNameCreator(firstNameProvider, lastNameProvider);

            firstNameProvider.Stub(n => n.GetFirstName()).Return("William");
            lastNameProvider.Stub(n => n.GetLastName()).Return("Clinton");

            // Act
            var result = fullNameCreator.Concatenate();

            // Assert
            Assert.That(result, Is.EqualTo("William Clinton"));
        }

        [Test]
        public void Can_Create_FullName_Using_AutoMockingContainer()
        {
            // Arrange
            var mocks = new MockRepository();
            var container = new Rhino.Testing.AutoMocking.AutoMockingContainer(mocks);
            container.Initialize();

            FullNameCreator fullNameCreator = container.Create<FullNameCreator>();

            using (mocks.Record())
            {
                container.Resolve<IFirstNameProvider>().Stub(r => r.GetFirstName()).Return("William");
                container.Resolve<ILastNameProvider>().Stub(r => r.GetLastName()).Return("Clinton");
            }

            // Act
            string result;
            using (mocks.Playback())
            {
                result = fullNameCreator.Concatenate();
            }

            // Assert
            Assert.That(result, Is.EqualTo("William Clinton"));
        }
    }
}

In the second test we have to apply RhinoMocks record-playback pattern. At this point there is no clear winner.

So now what if client/customer creates the following user story:

As a account administrator
I want to be able to see the first, middle and last name when I retrive customer information
So that I know their full name.

or for you behavior driven development fans

Given a customers’ first name is “William”, second name is “Jefferson” and third name is “Clinton”
When a user wants to retrieve their full name
Then “William Jefferson Clinton” should be returned

Doing this the test driven way, we can assume we will using a MiddleNameProvider and calling a method called ‘GetMiddleName’.

Without auto mocking it’s a case of creating a stubbed object, changing the constructor for the FullNameCreator and then setting up the stubbed object. With auto mocking it’s a one line code change.

[TestFixture]
public class FullNameCreatorTests
{
    [TestFixture]
    public class FullNameCreatorTests
    {
        [Test]
        public void Can_Create_FullName()
        {
            // Arrange
            var firstNameProvider = MockRepository.GenerateStub<IFirstNameProvider>();
            var middleNameProvider = MockRepository.GenerateStub<IMiddleNameProvider>();
            var lastNameProvider = MockRepository.GenerateStub<ILastNameProvider>();

            FullNameCreator fullNameCreator = new FullNameCreator(firstNameProvider, middleNameProvider, lastNameProvider);

            firstNameProvider.Stub(n => n.GetFirstName()).Return("William");
            middleNameProvider.Stub(n => n.GetMiddleName()).Return("Jefferson");
            lastNameProvider.Stub(n => n.GetLastName()).Return("Clinton");

            // Act
            var result = fullNameCreator.Concatenate();

            // Assert
            Assert.That(result, Is.EqualTo("William Jefferson Clinton"));
        }

        [Test]
        public void Can_Create_FullName_Using_AutoMockingContainer()
        {
            // Arrange
            var mocks = new MockRepository();
            var container = new Rhino.Testing.AutoMocking.AutoMockingContainer(mocks);
            container.Initialize();

            FullNameCreator fullNameCreator = container.Create<FullNameCreator>();

            using (mocks.Record())
            {
                container.Resolve<IFirstNameProvider>().Stub(r => r.GetFirstName()).Return("William");
                container.Resolve<IMiddleNameProvider>().Stub(r => r.GetMiddleName()).Return("Jefferson");
                container.Resolve<ILastNameProvider>().Stub(r => r.GetLastName()).Return("Clinton");
            }

            // Act
            string result;
            using (mocks.Playback())
            {
                result = fullNameCreator.Concatenate();
            }

            // Assert
            Assert.That(result, Is.EqualTo("William Jefferson Clinton"));
        }
    }
}

It’s not only a reduction in the amount of code we have to write. What you have to remember here is that any changes to the constructor for the FullNameCreator will break the non-auto mocked unit test.

Here’s an example to show what I mean. The customer/client decides they want to add logging. This has nothing to do with our expected outcomes. The code for the ILogger and changes to the FullNameCreator are shown below.

public interface ILogger
{
    void Log(string message);
}

public class FullNameCreator
{
    private readonly IFirstNameProvider _firstNameProvider;
    private readonly IMiddleNameProvider _middleNameProvider;
    private readonly ILastNameProvider _lastNameProvider;
    private readonly ILogger _logger;

    public FullNameCreator(IFirstNameProvider firstNameProvider, IMiddleNameProvider middleNameProvider, ILastNameProvider lastNameProvider, ILogger logger)
    {
        _firstNameProvider = firstNameProvider;
        _middleNameProvider = middleNameProvider;
        _lastNameProvider = lastNameProvider;
        _logger = logger;
    }

    public string Calculate()
    {
        _logger.Log("Getting the first name");
        var firstName = _firstNameProvider.GetFirstName();
        _logger.Log("Getting the middle name");
        var middleName = _middleNameProvider.GetMiddleName();
        _logger.Log("Getting the last name");
        var lastName = _lastNameProvider.GetLastName();
        return String.Format("{0} {1} {2}", firstName, middleName, lastName);
    }
}

This solution will not build because a unit test needs amending… no prizes for guessing which one!

At this point we can’t even just pass null, because the code will try and call the Log method. We have to create a stub object and pass it in.

For the unit test using the auto mocking container the addition of the logger made no difference whatsoever.

So am I writing all my tests using the auto mocking container? Sort of. When I’m doing test driven development I don’t like using the record playback syntax, I find it slows me down and takes my focus away from writing good unit tests. However when I have reached a point where the user story is complete and refactoring begins, I would adopt the auto mocking approach.

The other problem is that in order to use the automocking container I have to reference five libraries which is a bit of a pain and could lead to a whole host of version nightmares… more on that in another post.

The code is available at http://code.google.com/p/arrangeactassert/. The solution is in the AutoMockingContainer folder.

It has awesome new features such as data driven tests! See http://nunit.com/blogs/?p=66 for more information. That means I can now do the things only possible before in other frameworks such as MbUnit and xUnit.

Just be aware if you write your asserts like this

Assert.That(1, Is.EqualTo(1));

‘Is’ is now a member of ‘NUnit.Framework’ and not ‘NUnit.Framework.SyntaxHelpers’ so you will have to remove the using statement that looks like this

using NUnit.Framework.SyntaxHelpers;

If you find yourself having to create a class to hold ‘state’, like this

using System.Collections.Generic;

namespace GettingStartedWithRhinoMocks
{
    public class TestLogger : ILogger
    {
        public TestLogger()
        {
            Messages = new List<string>();
        }

        public IList<string> Messages { get; private set; }

        public void LogError(string errorMessage)
        {
            Messages.Add(errorMessage);
        }
    }
}

And your test looks something like this

[Test]
public void Will_Write_To_Log_If_Customer_Fails_Validation_When_Adding_Customer_Using_Stub()
{
	// Arrange
	ICustomerValidator customerValidator = MockRepository.GenerateStub<icustomerValidator>();
	var testLogger = new TestLogger();

	var customerService = new CustomerService(customerValidator, testLogger);

	customerValidator.Stub(c => c.IsValid(null))
		.IgnoreArguments() // Use this because the argument is not important
		.Throw(new ArgumentException(CustomerValidator.CUSTOMER_NAME_ERROR_MESSAGE));  // This will simulate the throwing of an exception

	//Act
	customerService.AddCustomer(new Customer());

	//Assert
	Assert.That(testLogger.Messages.Count, Is.EqualTo(1));
}

You can eliminate the need for the TestLogger class by using a mock like this

[Test]
public void Will_Write_To_Log_If_Customer_Fails_Validation_When_Adding_Customer_Using_Stub_And_Mock()
{
	// Arrange
	ICustomerValidator customerValidator = MockRepository.GenerateStub<icustomerValidator>();
	ILogger logger = MockRepository.GenerateMock<ilogger>();

	var customerService = new CustomerService(customerValidator, logger);

	customerValidator.Stub(c => c.IsValid(null))
		  .IgnoreArguments() // Use this because the argument is not important
		  .Throw(new ArgumentException(CustomerValidator.CUSTOMER_NAME_ERROR_MESSAGE));  // This will simulate the throwing of an exception

	// Act
	customerService.AddCustomer(new Customer());

	// Assert
	logger.AssertWasCalled(l => l.LogError(CustomerValidator.CUSTOMER_NAME_ERROR_MESSAGE));
}

The difference is how we assert the exception was logged. The extension method ‘AssertWasCalled’ ensures that the ‘LogError’ method of a logger was called with the correct error message.

If we changed the assert to this

//Assert
logger.AssertWasCalled(l => l.LogError("Oh no"));

The test would fail and RhinoMocks would throw the following exception

Rhino.Mocks.Exceptions.ExpectationViolationException: ILogger.LogError("Oh no"); Expected #1, Actual #0.

So over the two posts we have refactored the unit tests from not using a mocking framework to using both stub and mock functionality of a mocking framework and still have unit tests which are easy to read and maintain.

Martin Fowlers’ article discusses the two styles testing. I recommend you choose which is better on a test by test basis.

The code is available at http://code.google.com/p/arrangeactassert/. The solution is in the GettingStartedWithRhinoMocks folder.

I wanted to show an example of a unit test before and after implementing a mocking framework. My aim is to show why and how mocking frameworks (including Moq) can help you write unit tests more productively without compromising code readability or maintainability. Don’t worry if you’re new to writing unit tests or mocking frameworks, the examples should be easy enough to follow. If we have any questions just ask.

So here’s my take on it. I have split this post into two parts, stubs and mocks.

Anyway let’s get to the code. The goal is to create a unit test to assert ‘an error message is logged if a exception occurs when a user tries to add an invalid customer to a database’.

The emphasis shouldn’t be on the code per se, the aim is to keep it simple and easy to understand, after all validating objects is common practice! Notice how I’ve used the Arrange, Act and Assert layout so the test is easy to follow.

The code below shows:

• Customer object
• A interface for the logger
• A interface and class for customer validation
• A class for the customer service

using System;

namespace RhinoMocksDemo
{
    public class Customer
    {
        public string Name { get; set; }
    }

    public interface ICustomerValidator
    {
        bool IsValid(Customer customer);
    }

    public class CustomerValidator : ICustomerValidator
    {
        public const string CUSTOMER_NAME_ERROR_MESSAGE = "Customer name cannot be null or empty";

        public bool IsValid(Customer customer)
        {
            if (String.IsNullOrEmpty(customer.Name))
            {
                throw new ArgumentException(CUSTOMER_NAME_ERROR_MESSAGE);
            }
            return true;
        }
    }

    public interface ILogger
    {
        void LogError(string errorMessage);
    }

    public class CustomerService
    {
        private readonly ICustomerValidator _customerValidator;
        private readonly ILogger _logger;

        public CustomerService(ICustomerValidator customerValidator,ILogger logger)
        {
            _customerValidator = customerValidator;
            _logger = logger;
        }

        public bool AddCustomer(Customer customer)
        {
            try
            {
                if (_customerValidator.IsValid(customer))
                {
                    // Add it to the database
                    return true;
                }
            }
            catch (Exception exception)
            {
                _logger.LogError(exception.Message);
            }
            return false;
        }
    }
}

Notice the separation of concerns in the code as the customer validator and logger are passed (injected) in the constructor. It’s possible to use mocking frameworks without coding this way, and I might post on how to do that, but let’s stick to Uncle Bobs’ SOLID Principles for now.

So if I wasn’t using a mocking framework, I could write a test class that implements the logging interface and pass that into the constructor.

using System.Collections.Generic;
using NUnit.Framework;
using NUnit.Framework.SyntaxHelpers;

namespace RhinoMocksDemo
{
    public class TestLogger: ILogger
    {
        public TestLogger()
        {
            Messages = new List<string>();
        }

        public List<string> Messages { get; private set; }

        public void LogError(string errorMessage)
        {
            Messages.Add(errorMessage);
        }
    }

    [TestFixture]
    public class CustomerProviderTestFixture
    {
        [Test]
        public void Will_Write_To_Log_If_Customer_Fails_Validation_When_Adding_Customer()
        {
            // Arrange
            var customerValidator = new CustomerValidator();
            var testLogger = new TestLogger();

            var customerService = new CustomerService(customerValidator,testLogger);

            var customerWithNoNameThatIsFailVaidation = new Customer();

            //Act
            customerService.AddCustomer(customerWithNoNameThatIsFailVaidation);

            //Assert
            Assert.That(testLogger.Messages.Count,Is.EqualTo(1));
        }
    }
}

The test passes and the good news is we have a unit test that achieves our goal.

However there is a major problem here:

• We are to dependent on the validation class – i.e. we had to know how to make it throw an exception

A mocking framework provides us with the ability use a stub instead of an actual object. In the code below you can see the test now uses RhinoMocks to generate (a proxy for) the validation object as a stub. This allows you to control how the stubbed object should behave.

For our example when calling the IsValid method in the code an exception should be thrown.

        [Test]
        public void Will_Write_To_Log_If_Customer_Fails_Validation_When_Adding_Customer_Using_Stub()
        {
            // Arrange
            ICustomerValidator customerValidator = MockRepository.GenerateStub<icustomerValidator>();
            var testLogger = new TestLogger();

            var customerService = new CustomerService(customerValidator, testLogger);

            customerValidator.Stub(c => c.IsValid(null))
                .IgnoreArguments() // Use this because the argument is not important
                .Throw(new ArgumentException(CustomerValidator.CUSTOMER_NAME_ERROR_MESSAGE));  // This will simulate the throwing of an exception

            //Act
            customerService.AddCustomer(new Customer());

            //Assert
            Assert.That(testLogger.Messages.Count, Is.EqualTo(1));
        }

The unit test still passes and we are no longer dependent on how or what makes the validation class throw an exception.

The most common usage is to stub repositories because you don’t want to depend on a database, especially when it comes to continuous integration builds. The following example shows how to get famous people using a repository stub without ever having to create a concrete implementation of a famous people repository. This makes testing faster and allows you to focus on writing good unit tests for the subject under test.

using System.Collections.Generic;
using System.Linq;
using NUnit.Framework;
using Rhino.Mocks;

namespace GettingStartedWithRhinoMocks
{
    public class FamousPeople
    {
        public string Name { get; set; }
    }

    public interface IFamousPeopleRepository
    {
        IEnumerable<famousPeople> GetFamousPeople();
    }

    public class FamousPeopleService
    {
        private readonly IFamousPeopleRepository _famousPeopleRepository;

        public FamousPeopleService(IFamousPeopleRepository famousPeopleRepository)
        {
            _famousPeopleRepository = famousPeopleRepository;
        }

        public IEnumerable<famousPeople> NameStartsWithFilter(string searchText)
        {
            return _famousPeopleRepository.GetFamousPeople().Where(c => c.Name.StartsWith(searchText));
        }
    }

    [TestFixture]
    public class FamousPeopleServiceTestFixture
    {
        [Test]
        public void Can_Filter_FamousPeople_Using_Stub_To_Return_FamousPeople()
        {
            // Arrange
            var famousPeopleRepository = MockRepository.GenerateStub<ifamousPeopleRepository>();
            var famousPeopleService = new FamousPeopleService(famousPeopleRepository);

            famousPeopleRepository.Stub(c => c.GetFamousPeople()).Return(FamousPeopleStub);

            // Act
            var result = famousPeopleService.NameStartsWithFilter("Bill");

            // Assert
            Assert.That(result.Count(), Is.EqualTo(3));
        }

        private List<famousPeople> FamousPeopleStub
        {
            get
            {

                return new List<famousPeople>()
                           {
                               new FamousPeople(){Name = "Bill Gates"},
                               new FamousPeople(){Name = "Bill Clinton"},
                               new FamousPeople(){Name = "Bob Hope"},
                               new FamousPeople(){Name = "Billy The Kid"}
                           };
            }
        }
    }
}

The code is available at http://code.google.com/p/arrangeactassert/. The solution is in the GettingStartedWithRhinoMocks folder.

That’s it for part 1, in part 2 we will see how and where using mocks can make a difference!

I’ve just seen Seville who are second in the Spanish Football League resort to playing long balls that wouldn’t look out of place at Bolton or Blackburn. What’s more there’s no Sam Allardyce in sight. Seville were losing 2-0 at home against mid-table Racing Santander. With more than twenty minutes to go and playing against ten men, a team who are more than capable of playing it ‘on the deck’ started hoofing it. They still lost 2-0

Barcelona on the other hand have scored no less than 33 goals in the last twenty minutes of their games this season (see here). Even when coming from behind they still manage to play the kind of mouth watering football you expect from them.

So next time a deadline approaches ever closer don’t just sell your soul and ditch unit testing, try and play it cool and remain true of what you believe in.