Category: .NET

My last two posts regarding Rhino.Mocks, attracted quite a lot of attention. Focusing on solution I proposed for limiting complexity around creation different kinds of mocks, one thing was pointed out by few people as not the best solution. Ayende called it “in your face! API design”, that is stating the kind of mock you want to create explicitly, via method parameter.

I don’t think that doing it via method name is any less explicit, but let’s not go there. Instead, let’s think for a while – why do we need 4 kinds of mocks anyway?

All differences boil down to one thing – how the mock handles unrecorded calls:

• StrictMock (_repo.CreateMock overloads), any unexpected call results in exception being thrown.
• DynamicMock (_repo.DynamicMock overloads), any unexpected call returns default(T), where T is return type, that is null or 0 for value types.
• PartialMock (_repo.PartialMock overloads), this works only for classes and any unexpected call is not intercepted but forwarded to the actual method of that class.
• Stub (_repo.Stub), this is similar to DynamicMock with addition, that if you assign a value to a property, it remembers that value.

Those are all very important differences but I’d say quite subtle. Subtle to a point, that I am willing to agree that specifying them upfront either via explicitly named creation method, or via explicit parameter is throwing “in your face!” decisions that you shouldn’t have to be concerned about at this point.

Morten Lyhr noticed this as well, and he suggested the following solution:

public class LoginPresenterFixture

{

   private MockRepository _mockRepository;

   private LoginPresenter _loginPresenter;

   private LoginView _loginView;

   [SetUp]

   public void Init()

   {

      _mockRepository = new MockRepository();

      _loginView = _mockRepository.DynamicMock<LoginView>();

      CreateLoginPresenter();

   }

   private void CreateLoginPresenter()

   {

      _loginPresenter = new LoginPresenter(_loginView);

   }

   [Test]

   public void Strict_Test_Not_As_Often_Used()

   {

      //Override default mock kind

      _mockRepository.StrictMockBehaviour(_loginView);//this is important

      using (_mockRepository.Record())

      {

         Expect.Call(_loginView.ShowView);

      }

      using (_mockRepository.Playback())

      {

         _loginPresenter.Show();

      }

   }

}

It’s some way of dealing with it but it still requires you to explicitly assign behavior to mock object.

It’s still incorrect level of granularity though: instead of class level (different class per different mock kind) we now deal with it on object level (different kind per object).

I’d however move it yet one step further, to method level (different kind per method).

It might look something like this:

   [Test]

   public void Strict_Test_Not_As_Often_Used()

   {

      using (_mockRepository.Record())

      {

         Expect.Call(_loginView.ShowView);

         //Decide what to do with unexpected calls:

         Expect.For(_loginView).NothingElse();//this is important

      }

      using (_mockRepository.Playback())

      {

         _loginPresenter.Show();

      }

   }

Again, difference is very subtle, but important: instead of explicitly deciding about kind of mock, we decide about what to do about unexpected calls, which is more natural and closer to the actual problem. Different kinds of mocks, are just proposed solutions. The ‘kind’ is no longer a property of the mock object.

It also makes it easier to start with mocking framework: decision about what to do about unexpected calls is not thrown at your face at the very first lines, hidden behind terms like “Partial” or “Dynamic”. Instead you make that decision explicitly (and this time it’s a good thing) in last responsible moment that is in the actual test.

Last week I’ve read quite a few new blogposts about Moq mocking framework. I had looked at it once, when it was first released, but I didn’t find it interesting back then. Now that version 2.0 was released I decided to give it a go once again.

Here’s very simple model I created:

It’s a class with one method that uses helper object to obtain a value and possibly raise an event.

Here’s the whole code:

public interface IHelper

    {

        int Param { set; }

        string SomeMethod();

    }

    public class MyClass

    {

        public MyClass(IHelper helper)

        {

            Helper = helper;

        }

        public IHelper Helper { set; private get; }

        public event EventHandler MyEvent = delegate { };

        public void DoSomething(int parameter)

        {

            Helper.Param = parameter;

            string result = Helper.SomeMethod();

            if (result != null)

                MyEvent(null, EventArgs.Empty);

        }

    }

Now, to the fun part:

Let’s see how we can verify that when SomeMethod returns null, MyEvent is indeed not raised. First with Rhino.Mocks

   1:          [Test]

   2:          public void DoDomething_should_NOT_raise_MyEvent_when_helperSomeMethod_returns_null_Rhino()

   3:          {

   4:              var helper = _mocks.CreateMock<IHelper>();

   5:              var subscriber = _mocks.CreateMock<IEventSubscriber<EventArgs>>();

   6:              using (_mocks.Record())

   7:              {

   8:                  Expect.Call(helper.Param = 3);

   9:                  Expect.Call(helper.SomeMethod()).Return(null);

  10:                  DoNotExpect.Call(() => subscriber.Method(null, EventArgs.Empty));

  11:              }

  12:              using (_mocks.Playback())

  13:              {

  14:                  var sut = new MyClass(helper);

  15:                  sut.MyEvent += subscriber.Method;

  16:                  sut.DoSomething(3);

  17:              }

  18:          }

18 lines of code (you could cut that down to 13 simply by using ReplayAll() instead of Record() and VerifyAll in TearDown method instead of Playback, but I prefer it this way. My code is clean and quite well serves as documentation: Especially thanks to explicit usage of DoNotExpect.

The only awkward thing, is that whereas in both Expect call, I insert bare calls, in DoNotExpect.Call I had to use lambda. It’s a small inconsistency.

Now how would the same test look like with Moq?

   1:          [Test]

   2:          public void DoDomething_should_NOT_raise_MyEvent_when_helperSomeMethod_returns_null_Moq()

   3:          {

   4:              var helper = new Mock<IHelper>(MockBehavior.Strict);

   5:              var subscriber = new Mock<IEventSubscriber<EventArgs>>(MockBehavior.Strict);

   6:              helper.Expect(h => h.Param = 3);

   7:              helper.Expect(h => h.SomeMethod()).Returns((string)null);

   8:   

   9:              var sut = new MyClass(helper.Object);

  10:              sut.MyEvent += subscriber.Object.Method;

  11:              sut.DoSomething(3);

  12:          }

12 lines including one empty to visually divide setup part from testing part. Nice. There’s however one BIG problem with this code: it won’t compile. As I said earlier, You can’t have assignment in Expressions, and that’s what Moq is using, so if you want to set some properties on your mock… well – you’re out of luck. I also don’t like the fact that I have to cast null, to string. This seems redundant, but it’s only a small annoyance.

Bigger problem is that I can’t explicitly state that I expect MyEvent not to be raised.

Another thing, I couldn’t find a way to get hold of event raiser. I guess it’s just not there, so if you want to test events… you’re out of luck too.

Moq is interesting project for sure, it’s simple (simplistic) syntax made me think, about how complicated Rhino.Mocks became. Sure it’s orders of magnitude more powerful, but some unification of interfaces, even for a price of breaking some old code would be highly desired. I can imagine that for a newcomer current learning curve may seem steep. Especially the fact of using static classes makes API much less discoverable.

So I will stick to Rhino.Mocks, as it Moq is still to simple for serious use, but I’m glad it’s there. It brings some fresh ideas to the table, and there’s nothing better than a little competition.