1: public void SetCustomerPropertiesOnView(IEnumerable<Customer> customers)

   2: {

   3:     int count = 1;

   4:     string previousSurname = string.Empty;

   5:     foreach (var customer in customers)

   6:     {

   7:         this.View.AllCustomers.Add(new CustomerDisplay(customer));

   8:  

   9:         if (count == 1)

  10:             previousSurname = customer.Surname;

  11:  

  12:         if (customer.Surname != previousSurname)

  13:         {

  14:             this.View.SurnameFilter.Add(new NorthWindListItem(customer.Surname, customer.ID.ToString()));

  15:             previousSurname = customer.Surname;

  16:         }

  17:         count++;

  18:     }

  19: }

The context around this code is a view that shows all customers and allows the user to filter on surnames. Therefore I go and get the customers from the database I transform them for display and extract the unique surnames for the filtering functionality. I want to do all of this in one iteration of the customer list.

The above code achieves this aim, it may well be a naive implementation and there are other ways of doing this in a more efficient manner. That said the point of this post is to focus on the maintainability of this implementation, not it’s efficiency or approach. I would say that most developers would probably leave this implementation as is once they have achieved the goal. They would probably not be inclined to refactor this working solution into a more elegant solution that is maintainable over time.

My end solution to this problem looks like this

   1: public void SetCustomerPropertiesOnView(IEnumerable<Customer> customers)

   2: {

   3:     var customersAndSurnames = customers.TransformForDisplay().AndGetDistinctSurnames();

   4:  

   5:     this.View.AllCustomers = this.GetCustomersFrom(customersAndSurnames);

   6:     this.View.Surnames = this.GetUniqueSurnamesFrom(customersAndSurnames);

   7: }

The implementation of the two extension methods is not really that important in the end we still have the horrible implementation, but at the top level when the next guy comes along to add or maintain this code they will have some context around what we are trying to do. SetCustomerPropertiesOnView now has a more declarative style, you can see straight away that we are transforming customers for display and getting distinct surnames in order to give them to the view. The two private methods are just wrappers around extraction of the values in a C# implementation of a tuple, which is used to return two different types of values from one method without using out or ref parameters.

In conclusion once you have found a solution that works don’t just stop there, use the tests too aid your refactoring of a first attempt into a more maintainable elegant intention revealing block of code.

   1: public void SetCustomerPropertiesOnView(IEnumerable<Customer> customers)

   2: {

   3:     int count = 1;

   4:     var previousSurname = string.Empty;

   5:     foreach (var customer in customers)

   6:     {

   7:         this.View.AllCustomers.Add(new CustomerDisplay(customer));

   8:  

   9:         if (count == 1)

  10:             previousSurname = customer.Surname;

  11:  

  12:         if (customer.Surname != previousSurname)

  13:         {

  14:             this.View.SurnameFilter.Add(new NorthWindListItem(customer.Surname, customer.ID.ToString()));

  15:             previousSurname = customer.Surname;

  16:         }

  17:         count++;

  18:     }

  19: }

I will explain the reasons behind this code, and come up with a more refined solution in a later post. More often than not we come across implementations like this where the maintainer has to work really hard to get to the intent of the code.  In short this is an example of working code that is not easily maintainable over time, we can and should do better. With the safety net of unit tests I can now play around with this code to make it better.

This all goes back to Mike Waggs post on why he loves TDD/BDD particularly when he talks about tweaking code

“The best developers are those that continuously refine their code. They take something that is just a solution to the problem at hand and transform it into something which is clean and elegant. They craft a piece of code that is easily understandable by other developers and which can be easily maintained as the requirements of the system changes.”

I couldn’t agree more with this sentiment. The code above is a practical example of why we should strive to keep on tweaking. As I said before the code works, it does a job, should I walk away happy with this implementation. Absolutely not, we can make it better, so that the next person that has to delve into this code will get more understanding from reading it, not more questions.

Trying to understand this implementation will take time, to the business time is money and developer time is even more money. So for the good of the business don’t lock in your ignorance by leaving a first attempt at a solution to a problem, tweak it, until it clearly expresses your intent.

My solution will follow…what’s yours?

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.

I have been really spoilt by my first contract as the client I am working with does a lot of the Agile practices I have been looking for. The upper management believe and back these Agile practices such as close customer contact, TDD and continuous integration. In general the output from this team of developers is very stable with few issues coming back once released. Working for this client has convinced me more than ever that good Agile practices are the way to go when authoring Business software.

More on this later…for now I got work to do…

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

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

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.

Out came the old learn direct disk, which I have to say I was very impressed with, explaining all of the basic aspects of using the computer. The disk was packed with lots of little games to aid learning too control the mouse and such like. After about an hour of happy learning a dialogue box appeared, which had no cancel facility, luckily my other half was in the room at the time and being the jaded experienced user that she is the dialogue box said;

“If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No”

or words to that effect. So John was instructed to click OK and the problem dialogue box would go away. On clicking OK the sound disappeared, at this point first line support for all the families computer needs was summoned to the room. I did the usual checks to see that the sound was not turned down or that it had not been muted. The sound was coming out from the sound card to the speakers in the monitor, so I unplugged the cable and plugged it back in again causing the offending dialogue box to appear again.

As you can see the active window is asking “Which device did you plug in?”, so now I am being made to think, and as we all know users shouldn’t have to think. The device I plugged in was the line out to the monitor. So where is that option then, well ok trial and error time I went through them all and after getting no joy I was convinced that it must be the Rear speaker out option and that there must be a problem with the monitor. The assumption behind this option being, we had plugged the cable into the rear line out jack (I know, assumption is the mother of all….).

After reluctantly admitting defeat I took the machine back to PC world and explained the issue to the tech guys there, within a few minutes the guy came back handed me the base unit saying that it was all sorted. When asked what the fix was, he gave a little chuckle as if to say, don’t be a dumb user, and then said “you have to re-task the jacks, and that it was the front speaker out option”.

All’s well that ends’ well eh… Not really, to my mind it should not be that difficult to setup the sound from a computer’s sound card. The jacks are colour coordinated and so are the connecting cables. I have never had to learn what the colour coding means because on every other system I have setup I just plug the green cable from the speakers into the green jack on the system and hey presto as if by magic, we get sound. Quite simply to put the responsibility of re-tasking a jack into the hands of already overwhelmed novice users  is a poor design decision.

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.

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");
}

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


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

• 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.

My interest in computers began way way back in the days of windows 95/98. I had reached the dizzying heights of middle management in the service industry and now had to use a PC as part of my job. As a typical user I found them to be incredibly frustrating and always wanted to do things in a different way to that suggested by the help files. The frustration of not understanding what was going on under the hood led me on a quest through formal education in Internet computing at The London South Bank university. I graduated from University in 2005 and have been working on Asp.Net C# applications ever since.

I have started this blog for one simple reason: have you seen what’s happened to Jeff Attwood since he started waffling on in 2004? I figure i can waffle with the best of them, so watch out blogosphere I’m coming to get ya. Oh yeah and I also have a lot to learn and say on all the usual topics of agile software development. Also it makes a nice way for me to formalise my learning with a searchable repository of topics related to software development, as well as a place for me to vent about the software industry in general from time to time. Finally, if only one person learns something from my ramblings on these pages then I will be happy that my work was not in vain. Hi mum I am on the Interweb…

I have chosen the humble programmer as the title of my blog after the paper by Edsger W. Dijkstra. The essence of the paper struck a chord with my approach to software development:

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

Throughout university and in my short career thus far I have felt that our industry promotes the need to hide the fact that sometimes we just don’t get it. This attitude stops us asking the simple questions that need to be asked for fear of being labeled as stupid. After reading Dijkstra’s paper I realised that I had to be confident in what I do know and willing to work really hard to learn and understand what I don’t. I figure that by publishing what I do know that I might be able to help someone by passing on that knowledge. I also want to learn from the collective power of the web and I am sure that if my understanding of a topic is less than correct, people will let me know.