Given you’ve heard of BDD, When you try to get started, Then you will find much confusion and anger.

On my last project, as part of a developer wide shift I was introduced to Behaviour Driven Development. BDD has been gathering interest in the test driven community for quite some time. For a good background to this development technique it’s best to start at the beginning and  read Dan North’s article introducing BDD. From this article you can see the intention of BDD is to simplify a test first approach to software development,

I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.

The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.

thus lowering the entry level, which will increase take up amongst developers and the quality bar will be increased. Once you have read the article and, like me, felt an overwhelming desire to make the jump from boring old TDD to brand new BDD immediately, you will then mistakenly Google a phrase such as “Getting Started With BDD“. Ignoring the Microsoft articles you will avidly read anything and everything in this search result trying to grok BDD, unfortunately all you will find my friend, is confusion and anger.

In the end you must resist the urge to download any of the BDD frameworks out there until you have gotten your hands dirty writing your own implementation of BDD. Once you have become comfortable with this, by all means move onto a framework that allows you to bake the user stories into the tests rendering them unreadable at a glance etc. It’s your choice, we live in a democracy.

Getting started with BDD the pain free way.

first go to Ben Scheirman’s excellent article outlining the Transition from TDD to BDD, this will give you a clear grounding in making the move. Then have a play around with subclassing Ben’s base class and implementing some BDD test fixtures. Tim and Mike did this in my last company resulting in a nice simple framework that could be rolled out across the developer team with a minimal learning curve. The minimal learning curve is very important if you want take up of BDD, which is what the framework writers have forgotten in trying to cleverly bake trace ability from stories too behaviour into the test suite.

An example of our version of BDD would look like this:

   1: namespace specs_for_SessionManager

   2: {

   3:     public abstract class SessionManager_base_context : Specification<SessionManager>

   4:     {

   5:         protected Mock<ISession> Session { get; private set; }

   6:         protected String SessionName { get; private set; }

   7: 

   8:         protected override void EstablishContext()

   9:         {

  10:             Session = base.Substitute<ISession>();

  11:             Session.Setup(s => s.Close());

  12:             Session.Setup(s => s.BeginTransaction()).Returns(base.Substitute<ITransaction>().Object);

  13:         }

  14: 

  15:         protected override SessionManager CreateSubject()

  16:         {

  17:             return new SessionManager(Session.Object, SessionName);

  18:         }

  19:     }

Here I have my specifications for the SessionManager, I then subclass Bens base class and override the necessary methods to establish a context and create the system under test. I can then go on to create a scenario for different behaviours of the system.

   1: [TestFixture]

   2: public class when_closing_a_session : SessionManager_base_context

   3: {

   4:     protected override void When()

   5:     {

   6:         base.Subject.CloseSession();

   7:     }

   8: 

   9:     [Test]

  10:     public void underlying_session_should_be_called()

  11:     {

  12:         Session.AssertWasCalled(s => s.Close());

  13:     }

  14: }

  15: 

  16: [TestFixture]

  17: public class when_beginning_a_transaction : SessionManager_base_context

  18: {

  19:     protected override void When()

  20:     {

  21:         base.Subject.BeginTransaction();

  22:     }

  23: 

  24:     [Test]

  25:     public void a_transaction_should_have_begun_on_the_underlying_session()

  26:     {

  27:         Session.AssertWasCalled(s => s.BeginTransaction());

  28:     }

  29: }

As you can see we have a test fixture for each scenario, which overrides the when method in order to invoke the system under test in this context. Each test makes some assertion for expected behaviour in this scenario. Note the tests are now just one line assertions, we have split out the arrange and act part of the tests into the base class and the When method. The outcome of all this is a nice report in your resharper test runner like so;

This is a big step in the right direction, we can see the scenario that we are testing and the outcome of that behaviour being invoked, the only thing we are missing is the given. With the current style I found myself tacking on some context to the class name like so

when_beginning_a_transaction_with_a_pre_existing_transaction

This is not quite right, in my code I want to say Given a transaction is running When beginning a transaction Then an exception should be thrown, I can’t easily do that with the current structure so I tried using the namespace for the given and now my structure looks like this:

   1: 

   2: namespace base_context_for

   3: {

   4:     public abstract class session_manager : Specification<SessionManager>

   5:     {

   6:         protected Mock<ISession> Session { get; private set; }

   7:         protected Mock<ITransaction> Transaction { get; private set; }

   8:         protected String SessionName { get; private set; }

   9: 

  10:         protected override void EstablishContext()

  11:         {

  12:             Session = base.Substitute<ISession>();

  13:             Transaction = base.Substitute<ITransaction>();

  14:             Session.Setup(s => s.Close());

  15:             Session.Setup(s => s.BeginTransaction()).Returns(Transaction.Object);

  16:         }

  17: 

  18:         protected override SessionManager CreateSubject()

  19:         {

  20:             return new SessionManager(Session.Object, SessionName);

  21:         }

  22:     }

  23: }

  24: 

  25: namespace given_a_session_is_open

  26: {

  27:     [TestFixture]

  28:     public class when_closing_a_session : base_context_for.session_manager

  29:     {

  30:         protected override void When()

  31:         {

  32:             base.Subject.CloseSession();

  33:         }

  34: 

  35:         [Test]

  36:         public void underlying_session_should_be_closed()

  37:         {

  38:             Session.AssertWasCalled(s => s.Close());

  39:         }

  40:     }

  41: }

As you can see my base context is now in its own namespace called base_context_for, the base context class name is just the system under test. I can then subclass the base class with a fully qualified name, like so;

public class when_closing_a_session : base_context_for.session_manager

The above signature makes it really easy to see exactly what the system under test is and what the scenario is. 

On line 25 you will see that I have another namespace declaration to wrap the subclass, the namespace becomes the given, the class name is the when and the test methods correspond to then. Giving a nice resharper report like this:

For those of us that like to run TestDriven.Net, we will still get the same output when all is good

5 passed, 0 failed, 0 skipped, took 2.33 seconds.

but if you get a failing test you get the following output:

TestCase ‘given_a_transaction_already_exists.when_beginning_a_transaction.should_throw_invalid_operation_exception’

failed:
  Expected: instance of <System.InvalidOperationException>
  But was:  null

you can clearly see on the top line a full scenario description, which should make it nice and easy to figure out exactly what the issue is.

Conclusion

It is still early days for me and BDD but I am enjoying it and can see the benefit. For me BDD is all about giving an intuitive entry point into test first development, a by product of this is a nice report that developers can quickly see what is going wrong in their system under certain conditions. I think that trying to bake the full user story into the system at all levels of testing is a recipe for disaster. The frameworks for BDD seem to be geared towards the being able to trace a user story to some behaviour in your system. This leads to confusion for the developer, long overly noisy tests peppered with unmaintainable strings. The transition is now complete from TDD to BDD, until I have more experience in writing Behaviour fixtures I will stick to this structure. I would love to hear any of your thoughts (not you mum, my other reader, cheers big bro) on this structure and how it can be improved.

Mock Object Frameworks Part 3

In part 1 of this series I introduced the idea of substituting collaborating objects with test doubles in order to unit test your classes in isolation. In part 2 I then went on to introduce reasons to choose Rhino Mocks and the four types of test doubles rhino mocks gives you in order to carry out state or interaction based unit testing. In this article I am hoping to introduce testing events as well as some of the more common gotchas that catch out beginner users of Rhino mocks.

Understanding Error Messages

For beginner users of the Rhino mocks framework the biggest issue can be in trying to understand the error messages that are returned when an exception is thrown.

[Test]
public void Should_Call_GetById_When_Handling_The_View_Load_Event()
{
   this.Setup();
   IService<Customer> serviceMock = repository.StrictMock<IService<Customer>>();
   Expect.Call(serviceMock.GetById(4)).Return(this.customer);
   this.repository.ReplayAll();

   CustomerPresenter presenter = new CustomerPresenter(serviceMock, this.customerViewDMock);
   presenter.HandlePageLoad();
   this.repository.VerifyAll();
}

In the test method above I am creating a strict mock on line 3, I then set an expectation that the GetById() will be called and when it is, return the customer instance created earlier in the Setup(). The call to ReplayAll() on the repository lets the framework know that the record phase is complete and we are ready to playback any expectations during the execution of the unit under test. I then create the presenter instance and call the unit under test, which in this case is HandlePageLoad(). Finally I call VerifyAll() on the repository to assert that the expectations set earlier have been met.

When run the test fails with the following message;

Rhino.Mocks.Exceptions.ExpectationViolationException: IService`1.GetById(4); Expected #1, Actual #0.

As you can see an ExpectationViolationException has been thrown. The error message that we are interested in begins after the colon, it’s telling us that a call to IService.GetById(4) was expected once but actually called zero times. In this case I am doing an Interaction based test to ensure that GetById() on the service is called, because I have not implemented the HandlePageLoad() method on the presenter the expectation set in the record phase has not been met during the replay, resulting in the above exception. To fix this I add the following to the HandlePageLoad() method.

public void HandlePageLoad()
{
    Customer toDisplay = this.Service.GetById(4);
}

As you can see I have implemented just enough to get the test to pass, I have hard coded in the customer id in the call to GetById(4). In reality the customer id will be retrieved from the View.CustomerId property. I change the implementation to make the call to the view like so;

Customer toDisplay = this.Service.GetById(this.View.CustomerId);

Now I get the following error message.

Rhino.Mocks.Exceptions.ExpectationViolationException: IService`1.GetById<System.Int32>(0); Expected #0, Actual #1.
IService`1.GetById<System.Int32>(4); Expected #1, Actual #0.

Because I am using a strict mock the framework finds two expectation violations.

• GetById<System.Int32>(0); Expected #0, Actual #1 – is caused by the call to GetById() in the HandlePageLoad() implementation, because I am now getting the customer id from the view and I have not setup any value for it to return (the view is a strict mock controlled by the framework) customerid will always return the default value, in this case 0. The expectation violation is caused by the GetById(0) being called in the implementation and not having an Expect.Call(… etc set for it in the record phase of the unit test.
• GetById<System.Int32>(4); Expected #1, Actual #0 – is caused by the Expectation not being met for a call to the GetById(4) method with a parameter value of 4. We explicitly set this expectation in the unit test before the call to ReplayAll().

In short this whole issue is being caused by the parameter value being used in setting the expectation, I am using the hard coded value 4 in the expected call to GetById() but in the implementation GetById() is being called with the default customer id, which in this case is 0. We can remedy this situation by using IgnoreArguments like this;

Expect.Call(serviceDMock.GetById(4)).IgnoreArguments().Return(this.customer);

Adding a call to IgnoreArguments tells the framework to ignore any values passed into the call to GetById during the execution of the method under test. Now my test is more robust because it will fail when the GetById is not called but if the customer id property changes on the view it will have no effect on the test.

By carefully looking at the error message above we can see that the first part says that a call to IService.GetById(0) was not expected but called anyway and a call to IService.GetById(4) was expected but not met. With value types the clue is in the error message we can see the 0 and the 4 are the parameters making it that bit easier to figure out what is going on. When using reference types we get an even more cryptic error message, by changing the GetById so that it takes a Customer object setting the expectation looks like this;

Expect.Call(serviceMock.GetById(new Customer())).Return(this.customer);

and the new implementation looks like this;

//this is a simple implementation for demo purposes only
Customer toDisplay = this.Service.GetById(new Customer());

and when run the error message looks like this;

Rhino.Mocks.Exceptions.ExpectationViolationException: IService`1.GetById(Rhino.CommonGotchas.Customer); Expected #0, Actual #1.
IService`1.GetById(Rhino.CommonGotchas.Customer); Expected #1, Actual #0.

The parameter being passed in to the GetById(Customer) is the problem. When I set the expectation in the record phase of the unit test I passed in a new Customer and when I implemented the HandlePageLoad() method I also passed  in a new Customer in the call to GetById. The framework is using reference equals to check that the parameter being passed in the expectation is the same as the parameter being used in the actual implementation. In this case they are not, so we get the message GetById(Customer) wasn’t expected but actually called, GetById(Customer) was expected but never called. Again IgnoreArguments sorts this out but the error message is very confusing.

More Flexibility Using Dynamic Mocks

I get the two tier error message above because I am using strict mocks and as we all know from part 2 strict mocks will fail a test when either all expected calls have not been met or if unexpected calls are made on the mocked object during the execution of the unit under test. If however we use a dynamic mock in the above example we will only get the one error message. The framework will ignore the fact that a call has been made with the incorrect parameter and will fail on the fact that the expectation has not been met. The expectation has not been met because we have made an explicit expectation that a call to the GetById(param) will be called, we have not let the framework know that the parameters are not important so it will fail the verification. Once I tell the framework to ignore parameters the test will pass.

As a side note this is another reason why I am moving towards using dynamic mocks as apposed to strict mocks. They allow you to write more flexible interaction based tests that will fail for the right reason. So in the example above If someone refactors the implementation in such a way that the call to GetById(int) does not happen then the test will fail, the developer will see a failing test named Should_Call_GetById_When_Handling_The_View_Load_Event() and they can then decide whether in light of the refactoring this is a valid test or not.

Don’t Forget ReplayAll()

Not calling replay all on a series of expectations or when setting up results on stubs can cause many side effects, ranging from null pointer exceptions in the best case to an incorrectly passing test in the worst case. The most common time to be caught out by this scenario is when you are stubbing out a collaborator and you just want a quick one line way of setting up a result when the stub is called. The example in this section is for saving a customer that has been updated on the view to the database. The (contrived )  implementation  of the save method is as follows;

public void Save()
{
    Customer customer = this.View.GetCustomer();
    string phoneNumber = customer.Telephone;
    //do some validation on the phone number....
    this.Service.Save(customer);
}

I am getting the updated customer from the view, then getting the telephone number from the returned customer and validating that it meets some criteria finally I am saving it to the database. In my first test for this I want to ensure that only valid phone numbers are being saved to the database, so I stub the view and the service in order to assert state, like so;

[Test]
public void Should_Validate_PhoneNumber_Before_Saving()
{
    this.Setup();
    Service<Customer> serviceStub = repository.Stub<Service<Customer>>();
    ICustomerView viewStub = this.repository.Stub<ICustomerView>(); 

    Customer customerToSave = GetCustomerToSave(); 

    SetupResult.For(viewStub.GetCustomer()).Return(customerToSave);
    serviceStub.Save(new Customer());//Tell the framework a call to save, which is a void method will be made
    LastCall.Callback(new Delegates.Function<bool, Customer>(this.AssertPhoneNumberIsValid)); //Set a callback on the call to save so that I can assert on the phone number 

    CustomerPresenter presenter = new CustomerPresenter(serviceStub, viewStub);
    presenter.Save();
}

I then setup a result on the GetCustomer() method  telling the framework to return the dummy customer when it is called during the execution of the unit under test. On the next line I set a call to a the void method Save(customer) on the service, following it by setting a callback method on the lastcall made by the repository. This callback method will contain all of the assertions on the phone number to ensure that only valid customers are sent to the database. When I run this test I get a null pointer exception in the second line of the Save() method on the presenter. In this line I am trying to retrieve the telephone number from the customer returned from the view, but the view’s GetCustomer() is returning null. I have set a result on the call to GetCustomer() to return a customer instance so I should not be getting a null pointer. The reason behind this is because I have forgotten to call Repository.ReplayAll() to set the repository into the replay phase. Once I put in the missing line the test works as expected, the test now looks like this;

[Test]
public void Should_Validate_PhoneNumber_Before_Saving()
{
    this.Setup();

    Customer customerToSave = GetCustomerToSave();

    ...
    this.repository.ReplayAll();

    CustomerPresenter presenter = new CustomerPresenter(this.serviceStub, viewStub);
    presenter.Save();
}

As with all of these things I have options, first up I could use a using block with a call to Repository.Record() like this;

[Test]
public void Should_Validate_PhoneNumber_Before_Saving()
{
    this.Setup();
    Service<Customer> serviceStub = repository.Stub<Service<Customer>>();
    ICustomerView viewStub = this.repository.Stub<ICustomerView>();

    Customer customerToSave = GetCustomerToSave();

    using (this.repository.Record())
    {
        SetupResult.For(viewStub.GetCustomer()).Return(customerToSave);
        serviceStub.Save(new Customer());//Tell the framework a call to save, which is a void method will be made
        LastCall.Callback(new Delegates.Function<bool, Customer>(this.AssertPhoneNumberIsValid)); //Set a callback on the call to save so that I can assert on the phone number
    }

    CustomerPresenter presenter = new CustomerPresenter(serviceStub, viewStub);
    presenter.Save();
}

When the record block is exited a call to ReplayAll() is made behind the scenes in that way you don’t have to remember to call it explicitly. I feel that by using the block in this test increases the noise to code ratio making the code that little bit harder to understand. Also Record blocks are usually followed by PlayBack blocks that make the whole test easier to understand, as a rule of thumb I only use these blocks if I have 3 or more lines of expectations and Stubbed result setup in my tests. I feel that any less than that the using blocks cause too much noise for very little benefit. That is especially so in a state based test where you are purely stubbing out collaborators.

Setters and Stubs

Once you get passed the Record/Replay/Verify stuff and you have some understanding of the difference between Mocks/Stubs/Fakes/Dummies you will probably grow to enjoy using the framework to make your tests easier to write and maintain. As you get more accustomed to using the framework you will probably do as I did and forget that you don’t have to Setup Results on a stubbed object that has a read/write property, all you need to do is set the property on the stub and it will just work as expected. It seems obvious and it is obvious but you will probably forget about the setter and try to setup result like this;

the view interface

public interface ICustomerView
{
   int CustomerId { get; }
   Customer Customer { get; set; }
   void AttachDataSource(Customer dataSource);
   Customer GetCustomer();
}

As you can the Customer property is read/write the test method that stubs out the view is carrying on with the theme outlined above and looks like this;

[Test]
public void Should_Validate_PhoneNumber_Before_Saving()
{
   this.Setup();

   Customer customerToSave = GetCustomerToSave();

   SetupResult.For(this.viewStub.Customer).Return(customerToSave);
   serviceStub.Save(new Customer());//Tell the framework a call to save, which is a void method will be made
   LastCall.Callback(new Delegates.Function<bool, Customer>(this.AssertPhoneNumberIsValid)); //Set a callback on the call to save so that I can assert on the phone number
   this.repository.ReplayAll();

   CustomerPresenter presenter = new CustomerPresenter(this.serviceStub, viewStub);
   presenter.Save();
}

The third line of the test, in bold, sets up a result on the views’ customer property to return a dummy instance to save. It all looks very familiar, when I run this test I get the following error;

System.InvalidOperationException: Invalid call, the last call has been used or no call

has been made (make sure that you are calling a virtual (C#) / Overridable (VB) method).

As you can see from the test above I am calling a virtual method and a call has been made, I also don’t think knowing that the last call has been used really helps me in this scenario. The problem is being caused by me forgetting to set the Customer property directly on the Stubbed view like this;

[Test]
public void Should_Validate_PhoneNumber_Before_Saving()
{
   this.Setup();

   Customer customerToSave = GetCustomerToSave();

   this.viewStub.Customer = customerToSave;
   ...
}

Testing Events

There are two areas to testing events,

1. Test that subscribers attach to events correctly
2. Test that when thrown the event is handled

Thankfully rhino mocks gives us some mechanisms to carry out both types of tests. In my first test, again using the theme of a customer presenter instead of using direct calls from the view to the presenter I will be communicating through events. This first test is to ensure that when the presenter is constructed the Load event of the view is attached to. The test looks like this;

[Test]
public void Should_Attach_To_Page_Load_On_View()
{
    this.Setup();

    Expect.Call(() => this.customerViewDMock.Load += null ).IgnoreArguments();
    this.repository.ReplayAll();

    new CustomerPresenter(this.serviceStub, this.customerViewDMock);
    this.repository.VerifyAll();
}

As you can see it’s pretty straight forward, in the second line of the test I am setting up an expectation that something will attach to the Load event of the view. I then instruct the framework to IgnoreArguments on the expectation, in this case the null being attached to the Load event. You can also set constraints on the last call specifying things like Is.NotNull on anything attaching to the event. I then instantiate the presenter, which is the unit under test, and verify that all expectations have been met. In order to pass the test I implement the following constructor;

public CustomerPresenter(IService<Customer> service, ICustomerView view)
{
    this.Service = service;
    this.View = view;
    this.View.Load += ((sender, args) => Console.WriteLine("view loading"));
}

The next thing to test is handling the load event, the first test I want to do is an interaction based test to ensure that the GetById() method is called on the service. My test looks like this;

[Test]
public void Should_Call_GetById_On_Service_When_View_Loads()
{
    this.Setup();
    IService<Customer> serviceMock = repository.StrictMock<IService<Customer>>();

    IEventRaiser loadRaiser =
        Expect.Call(() => this.viewStub.Load += null).IgnoreArguments().GetEventRaiser();

    Expect.Call(serviceMock.GetById(4)).Return(new Customer());
    this.repository.ReplayAll();

    new CustomerPresenter(serviceMock, this.viewStub);
    loadRaiser.Raise(this.viewStub, EventArgs.Empty);
    this.repository.VerifyAll();
}

There are a few subtle differences from the original attach to load event test. I am now using a stub for the view, I set an expectation on the load event in order to get the event raiser, which I have called loadRaiser. This expectation on the stub will never be verified, meaning that the test is more robust to refactoring. I then set the expectation on the service that its’ GetById(4) is called finally setting the repository into replay mode. As in the attach test above, I instantiate the Presenter with the serviceMock and the viewStub. I then use the loadRaiser to Raise the load event, finally verifying that all expectations have been met. The implementation of the constructor now looks like this;

public CustomerPresenter(IService<Customer> service, ICustomerView view)
{
    this.Service = service;
    this.View = view;
    this.View.Load += ((sender, args) => service.GetById(4));
}

Conclusion

As I said from the outset, it is not straight forward, but my hope is that this series will be useful for those of you that wish to go down the route of incorporating dynamic mocking frameworks into your unit tests. This article should help you to avoid some of the pitfalls I went through in trying to understand the feedback from the framework. It should also go some way to convincing you that Rhino mocks gives you a lot of useful features to help you avoid the task of rolling your own fakes.

In the next article I will be writing about some of the new features in Rhino Mocks 3.5 beta and also comparing it with Moq to see which side of the religious argument I fall under.

Mock Object Frameworks Part 2

In the first instalment of this series I introduced the idea behind mocking showing a quick example of hand rolling your own stubs in order to test your classes in isolation. In this article I will be going through the types of test doubles you get from Rhino Mocks and why I chose it in the first place.  Rhino Mocks Documentation is a good starting point, after that there are plenty of people blogging on getting started with Rhino Mocks. You can also download and print a cheat sheet,  which is also very useful. For these reasons I won’t be delving too deeply into the usage of Rhino Mocks, I want to focus more on why you would choose it, what the different types of mock objects are and when to use them.

Why Choose Rhino Mocks?

In the previous instalment I outlined several mocking frameworks and some of their main features, at the time of my choosing a framework to use Moq wasn’t around, had it been I may have chosen that one, I will certainly be looking into some of the claims they make. So with this in mind I ended up going for Rhino Mocks. I discounted NMock2 and EasyMock because they use strings for setting expectations e.g.

Expect.Call("mockObject.SomeMethodOrProperty")

The problem with this approach is that if you change the name of any of the methods or properties being mocked the change will not be propagated to your tests. Refactoring is something I do all the time, as my understanding of the system improves I will refactor the code to express this new understanding. Visual Studio is improving in this area by giving us some basic refactoring support. The idea that I would have to do a search and replace in my test suite was a non starter in my mind.

In the end it was between Rhino Mocks and TypeMock. I discounted TypeMock because it’s too powerful. This may seem like a strange reason but I would urge all novice mockers to avoid TypeMock like the plague (links to typemock omitted deliberately ). The fact that you can mock anything is the problem, I believe in unit testing as a way of minimising bugs in your system, leading me to want to build testable systems. A deeply embedded dependency, such as a static call to a method that hits the database means that it cannot be tested in isolation without the use of TypeMock. So what, I hear you say, the system can still be tested and the method can be tested in isolation, so there is no problem right? Well if you have considered the effects of this embedded dependency and have decided that they are within acceptable boundaries then by all means carry on. You have done some thinking and recognised the tradeoffs and made an informed decision, that is what software development is all about, too avoid being a Cargo Cult Programmer. If on the other hand you embed that dependency because that is all you know, and with the help of TypeMock you can keep the coverage high as your system evolves into a nice big ball of mud, then you have problems, more specifically the maintainer of your code will have problems, lets hope they are not a psychopathic axe murder, or worse yourself.

Different types of test doubles

Out of the box Rhino gives us four different types of test doubles, each one is specific to different scenarios. The four are

Stub

Gives us a ready to use sub classed implementation of the collaborating class we want to substitute in our tests. A stub offers us a mechanism to inject test data into our unit under test without having the method call to the stub verified.  If you are doing a classic state based test where the unit under test collaborates with some object that you want to substitute then use a stub. Here is an example method that I want to test

public string FormatContactDetails(Message message)
{
    string contactDetails = message.GetContactDetails();
    //formating code here...
    return contactDetails;
}

This method could be from some messaging system where I want to get contact details from the given message, I don’t have any control over how the message is created I just know that it is part of the messaging framework. I want to do a state based test that the returned string is in the correct format, but I don’t want to go to the hassle of creating a Message instance because it may have too many dependencies on the framework. The test would look something like this

[Test]
public void Should_Return_ContactDetails_In_Correct_Format()
{
    MockRepository mockRepository = new MockRepository();
    //you could also use MockRepository.GenerateStub<Message>();
    Message messageStub = mockRepository.Stub<Message>();

    SetupResult.For(messageStub.GetContactDetails()).Return("some contact details");
    mockRepository.ReplayAll();

    Customer customer = new Customer();
    string formattedDetails = customer.FormatContactDetails(messageStub);

    //Make assertions on the state of formattedDetails
}

I create a stubbed message by calling Stub<Message>() on the repository of mocked objects. I then setup the test data to be used in the unit under test by calling SetupResult.For, this line tells the framework to return the string “some contact details” when GetContactDetails() is called during the execution of customer.FormatContactDetails, which is the unit under test. Calling mockRepository.ReplayAll() will move all of the mocked/stubbed objects in the repository from the record state into the replay state. Finally I can make all the assertions I need on the returned string to ensure that the formatted details are correct.

Dynamic Mock

Dynamic mocks give you loose replay semantics, this means that all expectations that are set must be met or your test will fail, but unexpected method calls will not cause the test to fail. You can use dynamic mocks as stubs but as the stub documentation suggests this is a lot of work for very little gain. Dynamic mocks come in handy on the rare occasion when you may have one method call to a collaborator that you care about whilst all other interactions with the same collaborator are not so essential.

UPDATE: 11.10.2008 – With the release of Rhino Mocks 3.5, Ayende confirmed what I had already concluded myself;

CreateMock is deprecated, replaced by StrictMock. The use of Strict Mock is discouraged

We should be using dynamic mocks instead of strict mocks, making our tests less brittle and easier to refactor.

Partial Mock

As the documentation suggests (the heading is a link ) partial mocks are useful for when you want to test abstract methods in isolation. Another use for partial mocks is when breaking dependencies in a legacy code base. By legacy code I mean untested tightly coupled spaghetti code that most of us see produced by the A grade whiz bang team assembled to get version 1 of the latest Greenfield project going, and this time they are going to get it right . Anyway an example of said code could be.

public string FormatContactDetails()
{
    string formattedDetails = string.Empty;
    ContactDetails details = ServiceController.Instance.GetContactDetails(this.CustomerID);
    //code to turn the contactDetails into a formatted string

    return formattedDetails;
}

In order to test the FormatContactDetails method in isolation I want to break the dependency on that static call to the database using the ServiceController. The point of my test at this stage is to ensure that the returned string is in the correct format, I don’t care about the database call, that should have been tested in an integration test suite. The first thing to do is to move it out into a public virtual method

public string FormatContactDetails()
{
    string formattedDetails = string.Empty;
    ContactDetails details = GetContactDetails();
    //code to turn the contactDetails into a formatted string

    return formattedDetails;
}

public virtual ContactDetails GetContactDetails()
{
    return ServiceController.Instance.GetContactDetails(this.CustomerID);
}

then I can sub class and override it in my tests. I can use a partial mock for this,

[Test]
public void Should_Get_formatted_ContactDetails_Without_Hitting_The_DB()
{
Customer customer = this.mockRepository.PartialMock<Customer>();

Expect.Call(customer.GetContactDetails()).Return("just testing");
this.mockRepository.ReplayAll();

string formattedAddress = customer.FormatContactDetails();

Assert.AreEqual("just testing", formattedAddress);
}

I have created a partial mock of the Customer class where the FormatContactDetails behaviour resides, I am then setting up an expected call on the virtual method GetContactDetails telling the framework that when the method call is executed return “just testing”. After moving the partial mock to the replay state from the record state I then call the unit under test. Finally I can make some assertions on the returned string to see that it is in the correct format, although I haven’t done in this test you can also verify that the expected call has been met.

Mock

Mock implementations of collaborating classes enable us to verify that methods were called correctly during the execution of the unit under test. Mocks are used when the interaction between a unit under test and it’s collaborators is the essence of the test. Mocking a collaborator gives us a strict record/replay model, this means that every expectation that is set must be met, also If a method is called on a mocked object without setting an expectation the test will fail.  When you mock an object using a call to CreateMock like so

Customer customer = this.mockRepository.CreateMock<Customer>();

you are saying that this is an interaction based test, the interaction between the unit under test and the mocked object is all important. It should be verified that all expectations have been met and that no calls have been made on the mocked object unexpectedly.

Conclusion

In this article I explained the reasons behind my choosing Rhino mocks for dynamically mocking dependent objects in my unit tests. I also went through the four types of test doubles that Rhino mocks gives you out of the box. These four types should give you all the functionality you need to unit test your classes in isolation without having too maintain a suite of hand rolled fakes, as you refactor your system. The important thing to realise is that there is more to a dynamic mock object framework than just pure mocking to enable interaction based testing. With this in mind you should have a clear understanding of what is important in each unit test and use the framework accordingly.

In the next instalment I will be outlining some general rules of thumb for incorporating Rhino mocks in your tests, I will also delve into some of the more common gotchas that may have you scratching your head when you first start using the framework.

Mock Object Frameworks

In the last 18 months I have been doing a good deal of experimentation with mock object frameworks. Trying to understand mocking frameworks, when to use them and when not to has been a painful experience, but one that I feel everyone should go through in order to come out the other side, with a deep seated knowledge of building testable systems. This is the first in a series of posts explaining my understanding of mock objects and the frameworks out there.

Introduction

Substituting real implementations of an interface with a mocked implementation is a technique used in unit testing that gives you the following benefits:

1. Keeps your unit tests fast running.
2. Enables you to test your classes in isolation.
3. Usually leads to a well designed loosely coupled system.

Fast running unit tests are essential to keeping the developers interested in running and maintaining test coverage during the development of a system. When I first tried unit testing a production system I soon became unstuck with tests that relied upon external resources that I had no control over such as database calls, SMTP, the file system etc. When this happens the tests become unrepeatable and slow, from then on other developers didn’t run the tests often, meaning that the test suite became an un trusted, maintenance nightmare with very little benefit. In order to keep your tests running fast you must mock out these external dependencies, tests that incorporate the database calls etc can, and should be included in an integration test suite that is separate from your unit tests. Points two and three are resulting side effects that are beneficial in their own right when you have a fast running, repeatable suite of unit tests.

The mistakes I made in the above mentioned project lead me down the path of Mock object frameworks. So far in this article I have used the term Mock to mean any type of implementation used as a substitute in your tests. There are several different types of Test Doubles that can be used, each of them enable you to take different approaches in your unit tests. Over this series of articles I will be delving more deeply into the different approaches to writing unit tests but for now I will use Martin Fowler’s definitions from his article Mocks Aren’t Stubs without going into too much detail.

Mock objects

pre-programmed with expectations which form a specification of the calls they are expected to receive

Stubs

provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.

Fakes

objects actually have working implementations, but usually take some shortcut which makes them not suitable for production

A common example throughout these articles will be to develop a Presenter that collaborates with a view and a model (MVP), I will be substituting implementations of these dependent objects with mocks/stubs/fakes. This allows me to construct the presenter without worrying about the implementation details of the view and the model. In my opinion this is a very important benefit of mocking because it allows me to concentrate on doing one thing and one thing only.

The Manual Approach

The manual approach to achieving this isolation is to implement your own stubs that return test data when the methods are called. The following is a CustomerOrdersPresenter that interacts with an ICustomerOrdersView and an IDataProvider (the model). In the constructor of the presenter I want to attach to the views load event so my test for this is…

[Test]
public void Should_Attach_To_Load_Event()
{
ICustomerOrdersView customerOrdersViewStub = new CustomerOrdersViewStub();
CustomerOrdersPresenter presenter =
new CustomerOrdersPresenter(customerOrdersViewStub, _customersDataProvider);
Assert.IsNotNull(presenter, "Presenter should not be null");
Assert.IsTrue(((CustomerOrdersViewStub)customerOrdersViewStub).InvocationListCount > 0,
"the invocation list of the Load event should be greater than 0");
}

As you can see I have created a new instance of the CustomerOrdersViewStub, which is my own hand rolled implementation of the ICustomerOrdersView. As well as implementing the interface functionality I have added some properties and methods to allow me to write useful tests. In this case I have added a InvocationListCount property that allows me to get at the Load events invocation list.

internal class CustomerOrdersViewStub : ICustomerOrdersView
{
//ICustomersView implementation
....
//added property for testing
public int InvocationListCount
{
get { return this.Load.GetInvocationList().Length; }
}
}

Finally the implementation of the CustomerOrdersPresenter’s constructor is

public class CustomerOrdersPresenter
{
private readonly ICustomerOrdersView _view;
private readonly IDataProvider _provider;
public CustomerOrdersPresenter(ICustomerOrdersView view) :this(view, new CustomerDataProvider())
{ }
public CustomerOrdersPresenter(ICustomerOrdersView view, IDataProvider provider)
{
_view = view;
_provider = provider;
_view.Load += new EventHandler(View_Load);
}
}


The benefits of the manual method are

• No learning curve (we all know how to write code).
• Complete control over the stub

The downside of the manual method is

• Can quickly become a nightmare to maintain two sets of implementations.
• A lot of code to write just to get useful fine grained tests.

Although the downside to the manual method is quite significant I would advise anyone starting out unit testing to use it until they are completely happy with writing good unit tests. With hindsight I probably went over to mock object frameworks too early in my unit testing career, this lead to a lot of frustration with trying to learn two things at once.

Mocking Frameworks

In order to avoid writing your own stubs for testing purposes you can incorporate a mock object framework to do the work for you. As I said earlier I found the learning curve is pretty steep but as with all things it gets easier over time. Of course some of you geniuses out there will probably get it straight away, or you may have a colleague who has used the frameworks before. All I can say is give yourself a pat on the back and sit back with your hands cradling the back of your head allowing a nice smug grin to appear on your face.For the rest of us the different frameworks are:

• TypeMock
  • Free and professional versions.
  • Allows you to mock anything, including static methods.
  • Has a fluent interface.
  • pro version is quite expensive.
  • You don’t have to inject mocked objects
• NMock2
  • Free open source project.
  • Allows you to mock classes and interfaces.
  • Uses strings to set the expectations on method calls.
  • Uses a fluent interface.
  • You have to inject dependent mock implementations in order to set expectations on them.
• RhinoMocks
  • Free open source project.
  • Allows you to mock classes, interfaces and delegates.
  • Developed with refactoring in mind, by using the strongly typed mock object’s instead of strings to set your expectations.
  • Uses a fluent interface.
  • You have to use Dependency Injection in order to substitute the real implementation with a mock/stub.
• MoQ
  • Free open source project.
  • Allows you to mock classes, interfaces and delegates.
  • Uses strongly typed mocks when setting expectations.
  • Uses a fluent interface.
  • No record/replay/verify syntax

With the exception of MoQ all of the frameworks use a record/replay/verify model. This means that you record a set of expected behaviour then you verify that all of the expectations were met after the replay. The record/replay model is only important when you are using pure mock objects (not stubs) in an interaction based test. State based testing is the more familiar to most developers, where you set up some test data and call the unit under test and assert that the state of the object meets some post condition. When doing interaction based testing the assertions being made are based on the interaction between the unit under test and its’ collaborators. This will hopefully become clearer as I produce some demo code in later instalments of this series.

In the next article I will be delving into the reasons behind why I chose RhinoMocks. I will also be showing more code examples of writing unit tests using RhinoMocks.