Comments on: Working With Assertions Made on Arguments in Rhino Mocks

By: Chris Missal

Chris Missal — Thu, 18 Mar 2010 18:01:32 +0000

@Chad

You’re right on the SOLID issues, but I wouldn’t say that they’ve caused pain. I just had the one hiccup that I mentioned above. I could actually modify these pretty easily. The code doesn’t show it above (cause I accidentally omitted it), but the CustomerServiceNotifier is an INotifier, which are injected via our container. It would pretty easy to add the idea of Match() and BuildNotification() methods. We only have a few of these right now, but if/when that area grows, that could be really helpful. Good thoughts!

By: chadmyers

chadmyers — Thu, 18 Mar 2010 17:14:29 +0000

Looking through this, it feels like you’ve got an OCP and maybe an SRP issue, which is why you’re feeling the pain of the mock troubles here.

The “if (order.HasNotes)” code feels like OCP violation as it’s somewhat similar to a switch/case statement block. Perhaps you should consider having strategies with a Match() method and a BuildNotification() method. The strategies get injected via IoC and your Notify() method just iterates the strategies and if they Match() on the current Order, then you call BuildNotification() and the strategy will append whatever it needs to the notification.

By: Chris Missal

Chris Missal — Thu, 18 Mar 2010 15:42:46 +0000

@MM

Correct, multiple assertions would have pointed to a better failure sooner. I’m just thinking that taking it one step further and breaking them into their own tests would be an even better step. After all, they are individual requirements we want to ensure are working as expected.

By: Chris Missal

Chris Missal — Thu, 18 Mar 2010 15:41:09 +0000

@Garry

I think you might be right, a hand-rolled mock might make things a bit more concise here. I use them sometimes, usually when subclassing an object to test it.

By: MM

MM — Thu, 18 Mar 2010 15:14:48 +0000

The ironic thing is, multiple assertions would have probably allowed you to find the problem faster.

emailService.AssertWasCalled(x => x.SendOrderReceived(
Arg.Is.Anything,
Arg.Matches(body => body.Contains(“This order needs a shipping quote.”))));

emailService.AssertWasCalled(x => x.SendOrderReceived(
Arg.Is.Anything,
Arg.Matches(body => body.Contains(customerNumber.ToString()))));

emailService.AssertWasCalled(x => x.SendOrderReceived(
Arg.Is.Anything,
Arg.Matches(body => body.Contains(orderNumber.ToString()))));

This might make the test less readable but you would have seen which Contains was failing.

I think it’s debatable as to whether you’re actually testing three things in this case (regardless of how many actual assertions you have). You’re really just checking the contents of one argument. Three separate tests might be overkill but I’m not sure.

By: Greg Sohl

Greg Sohl — Thu, 18 Mar 2010 13:56:37 +0000

I don’t have a problem with multiple Asserts in a test, as long as each produces a proper message. For example, in recently testing a thread-safe cache, after adding an item, there were multiple counters that should be set to particular values. The “Add” test verifies all those counters with multiple Asserts and clear messages on failure.

By: Garry Shutler

Garry Shutler — Thu, 18 Mar 2010 12:07:08 +0000

In this kind of scenario I find it much easier to hand-roll my mock object. Then you can expose a property like “LastSentOrderBody” which lets you split up the assertions. This gives you much finer grained assertions which prevents this sort of problem.