So which mocking framework should we use? Do we fall back on good old Rhino Mocks or do we choose for the new kid on the block Moq?

From a technical point of view i would dare to say that they will be able to support the same set of features because they’re both based on Castle’s DynamicProxy. Rhino Mocks has the advantages that it, unlike Moq, supports the mocking of Delegates and can be used in a .Net 2.0 only environment. Whether or not we should care about these differences is a question i will leave unanswered.

From a user point of view i find the Moq API a bit cleaner because it frees me from thinking about the record-replay model and Rhino Mocks wants me to make assertions on a stub. Apart from that the differences are rather small given for the use-cases i presented in Getting started with Moq.

• Creating instances:

  // Rhino
  var productDetailView = MockRepository.GenerateStub<iproductDetailView>();

  
  

  // Moq
  var productDetailViewMock = new Mock<iproductDetailView>();

• Setting up results:

  // Rhino Mocks
  productRepository
    .Stub(repository => repository.GetCategory(0)).IgnoreArguments()
    .Do((Delegates.Function<icategory, int>)(categoryId => return category;));

  
  

  // Moq
  productRepositoryMock
    .Setup(repository => repository.GetCategory(It.IsAny<int>()))
    .Returns<int>(categoryId => return category.Object;});

• Consuming the mocked objects:

  // Rhino Mocks
  // Nothing to do

  
  

  // Moq
  // Nothing to do

• Raising events:

  // Rhino Mocks
  productDetailView.Raise(view => view.EditClick += null).Raise(sender, EventArgs.Empty);

  
  

  // Moq
  productDetailViewMock.Raise(view => view.EditClick += null, sender, EventArgs.Empty);

• Verifying that a method was invoked:

  // Rhino Mocks - Odd that i'm asserting on a Stub.
  productRepository.AssertWasCalled(
    repository => repository.FindCategories(
      Arg<ispecification<icategory>>.Matches(Is.TypeOf(typeof(All<icategory>)))));

  
  

  // Moq
  productRepositoryMock.Verify(
    repository => repository.FindCategories(
      It.Is<ispecification<icategory>>(specification => specification.GetType() == typeof(All<icategory>))));

• Override a result

  // Rhino Mocks
  productDetailView.BackToRecord();
  
  productDetailView
    .Stub(view => view.CategoryId)
    .Returns(2);

  
  

  // Moq
  productDetailViewMock
    .Setup(view => view.CategoryId).Returns(2);

Editted code to take advantage of the new AAA syntax that comes with Rhino Mocks 3.5 If only someone could show me how i can override a Stubbed result…

In this article I will demonstrate the Moq API by means of a simple application that allows the user to manage a quote.

In order to prevent that we have to rewrite our application when we move to a different graphical environment such as Web Forms, Silverlight or WPF I have decided to apply the Humble Object pattern in the design. The implementation of the application has been based on the Passive View pattern.

First we describe what should happen when the user launches the application:

• The quote should be displayed
• The Edit button should be visible
• The OK button should be invisible
• The Cancel button should be invisible
• It should not be possible to edit the quote

Now we translate these requirements in code. Because it is too expensive to test with actual Windows resources I have decided to use a mock object that mimics the actual resource. This is done in the Given method which arranges the context in which we want to verify the behavior:

this.quoteFormViewMock = new Mock<iquoteFormView>();
// The mimicked view object is available via the Object property
this.sut = new QuoteFormPresenter(this.quoteFormViewMock.Object);

The When method is used to invoke the behavior that we want to verify. In the situation where the user launches the application this means raising the Load event:

this.quoteFormViewMock.Raise(view => view.Load += null, null, EventArgs.Empty);

We can verify that a certain method has been called as following:

this.quoteFormViewMock.Verify(view => view.MakeEditButtonVisible(true));

In situations where we don’t have the exact parameters for the method that should be invoked we can use the It class to describe those parameters:

this.quoteFormViewMock.Verify(view => view.DisplayQuote(It.IsAny<string>()));

We repeat this process of defining and implementing the requirements for the other interactions we want to describe. We end up with a set of requirements that looks like this:

In case the user clicked the Cancel button we want to verify that the updated quote is not displayed:

this.quoteFormViewMock.Verify(view => view.DisplayQuote(It.IsAny<string>()), Times.Never());

In case the user clicked the OK button we have to ensure a context where an updated quote is available. This is achieved by adding the following in our Given method:

this.quoteFormViewMock
  .Setup(view => view.UpdatedQuote)
  .Returns(this.updatedQuote);

Now we can verify that the updated quote is displayed:

this.quoteFormViewMock.Verify(view => view.DisplayQuote(this.updatedQuote));

Virtually every application interacts with a database and the same is true for our application. Just like we abstracted our view, we decide to abstract our quote resource too. In case the user clicked the OK button we want to verify that the resource was instructed to update the quote.

var quote = this.quoteFormViewMock.Object.UpdatedQuote;
this.quoteResourceMock.Verify(resource => resource.Update(quote));

In case the quote resource fails we would like to display an error message. To achieve this we create a new test that establishes a context where the quote resource throws an exception when it is asked to update a quote as following:

base.Given();
base.quoteResourceMock
  .Setup(resource => resource.Update(It.IsAny<string>()))
  .Throws(new ApplicationException("Resource is unavailable."));

Sometimes we want to determine what should happen based on the parameters that are provided. In that case we can provide the Returns function a delegate:

base.quoteResourceMock
  .Setup(resource => resource.Update(It.IsAny<string>()))
  .Returns<string>(quote =>
  {
    if (string.IsNullOrEmpty(quote)) throw new ApplicationException();
    return quote.Replace("a", "b");
  });

I think that this covers most typical usage scenarios. Feel free to download the code: QuoteManager.zip.

In the Quickstart guide we find an example that shows us how to setup a different return value for each invocation as following:

// returning different values on each invocation
var mock = new Mock<ifoo>();
var calls = 0;
mock.Setup(foo => foo.Execute("ping"))
    .Returns(() => calls)
    .Callback(() => calls++);
// returns 0 on first invocation, 1 on the next, and so on
Console.WriteLine(mock.Object.Execute("ping"));

In Moq Triqs – Successive Expectations i found inspiration to implement an extension method that allows me to define an expectation that calls a set of successive functions:

public static class MoqExtensions
{
 public static IReturnsResult<tmock> ReturnsInOrder<tmock, TResult>(this ISetup<tmock, TResult> setup, params Func<tresult>[] valueFunctions) where TMock : class
 {
  var functionQueue = new Queue<func<tresult>>(valueFunctions);
  return setup.Returns(() => functionQueue.Dequeue()());
 }
}

This allows me to define a set of functions that i want to be called for each successive call:

public class WhenSettingUpOrderedExpectationFunctions
{
 interface ICategory { int Id { get; } }

 [Fact]
 public void ShouldReturnTheSequenceOfIds()
 {
  var category = new Mock<icategory>();

  category.Setup(c => c.Id).ReturnsInOrder(
   () => 1,
   () => 2,
   () => 3,
   () => 4);

  var expectedIds = new List<int> { 1, 2, 3, 4 };
  foreach (var expectedId in expectedIds) Assert.Equal(expectedId, category.Object.Id);
 }
}