Someone once said something like: “Code is written once and read many times”. That is why I propose not to use RhinoMocks’ AssertWasCalled method for methods that accept parameters. Sure, it’s written faster than using GetArgumentsForCallsMadeOn, but check out the error message you get for this:

var expectedMessage = "RhinoMocks baby!";
var actualMessage = "RhinoMocks dude!";
var fooMock = MockRepository.GenerateMock();

fooMock.Bar(actualMessage);

fooMock.AssertWasCalled(x => x.Bar(expectedMessage));

Your test will fail with the following message:

IFoo.Bar("RhinoMocks baby!"); Expected #1, Actual #0.

To fix this is actually a bit of a hassle. You have to debug the test and compare the parameters by hand. Replace the above with GetArgumentsForCallsMadeOn:

var expectedMessage = "RhinoMocks baby!";
var actualMessage = "RhinoMocks dude!";
var fooMock = MockRepository.GenerateMock();
fooMock.Bar(actualMessage);

var calls = fooMock.GetArgumentsForCallsMadeOn(x => x.Bar(string.Empty), o => o.IgnoreArguments());
Assert.AreEqual(1, calls.Count);
var arguments = calls[0];
Assert.AreEqual(expectedMessage, arguments[0]);

This is your failing test message now:

String lengths are both 16. Strings differ at index 11.
Expected: "RhinoMocks baby!"
But was:  "RhinoMocks dude!"
----------------------^

Much more readable and clear, no? * While you’re actually making the error message more readable and not the code, I believe it falls into the same adage. Think about who’s reading/using it afterwards (it might even be you!), not about taking shortcuts because it’s less typing