Corey Coogan

One of the common tasks I come across when doing TDD is mocking events.  I’m a big fan of Rhino Mocks and it’s pretty easy to raise an event on a mocked object doing something like this:

_Broker.Raise(x => x.GetData += null, this, EventArgs.Empty);

This is representative of the most typical examples you’ll find on the web and this is all fine and good.  However, sometimes the scenario that you need to test is a little more complicated and this method of raising events on a mock object simply won’t work without too many hassles.

A More Complicated Scenario

A common scenario may be where you are testing something that is subscribing to events that are actually fired by an object a couples levels deep.  For example, you may have an object that sends messages to another object, which is responsible for raising the event.  Hopefully this very simple textual sequence figure will help make things more clear.

Proxy.Execute() -> Broker.HandleMessage() -> Broker.RaiseEvent() -> Gateway.HandleEvent(eventArg)

I want to test that when the Proxy publishes a certain message the Gateway handles the event properly.

Mocking The Old Fashioned Way

My first instinct was to look at how I could accomplish this with Rhino.  After a couple minutes, I realized that this would not be a good way to spend my time.  A better option for me was to mock the old fashioned way.  To do this, I created a MockProxy and MockBroker class that implemented the IProxy and IBroker interfaces.  I can now just write regular C# code to handle how/when to raise those events.  It took only a few minutes to write the code, is intention-revealing and works like a champ.

NOTE: I tried to figure out how I could show some sample code without getting into all the gory details but couldn’t find a simple way, so I’ll just get right to the moral of the story.

When it comes to mocking, follow the KISS principal.  Rhino and other frameworks are there to make our lives easier.  If you are spending time and effort trying to figure out how to mock something in a framework, stop and think about doing it old school.  You’ll save yourself a load of time and your simple solution should be more readable to others.  You can still create a Rhino mock of your old school mock object (assuming you used virtual methods) for the purpose of asserting expectations, which will provide the best of both worlds.