Krzysztof Koźmic's blog

My last two posts regard­ing Rhino.Mocks, attracted quite a lot of atten­tion. Focus­ing on solu­tion I pro­posed for lim­it­ing com­plex­ity around cre­ation dif­fer­ent kinds of mocks, one thing was pointed out by few peo­ple as not the best solu­tion. Ayende called it "in your face! API design", that is stat­ing the kind of mock you want to cre­ate explic­itly, 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 dif­fer­ences boil down to one thing — how the mock han­dles unrecorded calls:

• Strict­Mock (_repo.CreateMock over­loads), any unex­pected call results in excep­tion being thrown.
• Dynam­ic­Mock (_repo.DynamicMock over­loads), any unex­pected call returns default(T), where T is return type, that is null or 0 for value types.
• Par­tial­Mock (_repo.PartialMock over­loads), this works only for classes and any unex­pected call is not inter­cepted but for­warded to the actual method of that class.
• Stub (_repo.Stub), this is sim­i­lar to Dynam­ic­Mock with addi­tion, that if you assign a value to a prop­erty, it remem­bers that value.

Those are all very impor­tant dif­fer­ences but I'd say quite sub­tle. Sub­tle to a point, that I am will­ing to agree that spec­i­fy­ing them upfront either via explic­itly named cre­ation method, or via explicit para­me­ter is throw­ing "in your face!" deci­sions that you shouldn't have to be con­cerned about at this point.

Morten Lyhr noticed this as well, and he sug­gested the fol­low­ing 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 deal­ing with it but it still requires you to explic­itly assign behav­ior to mock object.

It's still incor­rect level of gran­u­lar­ity though: instead of class level (dif­fer­ent class per dif­fer­ent mock kind) we now deal with it on object level (dif­fer­ent kind per object).

I'd how­ever move it yet one step fur­ther, to method level (dif­fer­ent kind per method).

It might look some­thing 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, dif­fer­ence is very sub­tle, but impor­tant: instead of explic­itly decid­ing about kind of mock, we decide about what to do about unex­pected calls, which is more nat­ural and closer to the actual prob­lem. Dif­fer­ent kinds of mocks, are just pro­posed solu­tions. The 'kind' is no longer a prop­erty of the mock object.

It also makes it eas­ier to start with mock­ing frame­work: deci­sion about what to do about unex­pected calls is not thrown at your face at the very first lines, hid­den behind terms like "Par­tial" or "Dynamic". Instead you make that deci­sion explic­itly (and this time it's a good thing) in last respon­si­ble moment that is in the actual test.

Last week I've read quite a few new blog­posts about Moq mock­ing frame­work. I had looked at it once, when it was first released, but I didn't find it inter­est­ing back then. Now that ver­sion 2.0 was released I decided to give it a go once again.

Here's very sim­ple model I created:

It's a class with one method that uses helper object to obtain a value and pos­si­bly 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 ver­ify 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 sim­ply by using Replay­All() instead of Record() and Ver­i­fyAll in Tear­Down method instead of Play­back, but I pre­fer it this way. My code is clean and quite well serves as doc­u­men­ta­tion: Espe­cially thanks to explicit usage of DoNotExpect.

The only awk­ward 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 includ­ing one empty to visu­ally divide setup part from test­ing part. Nice. There's how­ever one BIG prob­lem with this code: it won't com­pile. As I said ear­lier, You can't have assign­ment in Expres­sions, and that's what Moq is using, so if you want to set some prop­er­ties 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 redun­dant, but it's only a small annoyance.

Big­ger prob­lem is that I can't explic­itly 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 inter­est­ing project for sure, it's sim­ple (sim­plis­tic) syn­tax made me think, about how com­pli­cated Rhino.Mocks became. Sure it's orders of mag­ni­tude more pow­er­ful, but some uni­fi­ca­tion of inter­faces, even for a price of break­ing some old code would be highly desired. I can imag­ine that for a new­comer cur­rent learn­ing curve may seem steep. Espe­cially the fact of using sta­tic classes makes API much less discoverable.

So I will stick to Rhino.Mocks, as it Moq is still to sim­ple for seri­ous use, but I'm glad it's there. It brings some fresh ideas to the table, and there's noth­ing bet­ter than a lit­tle competition.