A while back I wrote about mocking successive calls to the same method which returns a sequence of objects. Read that post for more context. In that post, I had written up an implementation, but quickly was won over by a better extension method implementation from Fredrik Kalseth. public static class MoqExtensions
{
public static void ReturnsInOrder<T, TResult>(this ISetup<T, TResult> setup,
params TResult[] results) where T : class {
setup.Returns(new Queue<TResult>(results).Dequeue);
}
}
As good as this extension method is, I...
UPDATE: For a better approach, check out MoQ Sequences Revisited.
One area where using MoQ is confusing is when mocking successive calls to the same method of an object. For example, I was writing some tests for legacy code where I needed to fake out multiple calls to a data reader. You remember data readers, don’t you? Here’s a snippet of the code I was testing. Ignore the map method and focus on the call to reader.Read. while(reader.Read()) {
yield return map(reader);
}
Notice that there are multiple calls...
UPDATE: I should have entitled this “Comparing Rhino Mocks and MoQ for State Based Testing”. I tend to prefer state-based testing over interaction based testing except in the few cases where it is absolutely necessary or makes the test much cleaner. When it is necessary, it is nice to have interaction based testing available. So my comparison is incomplete as I didn’t compare interaction based testing between the two frameworks. For the longest time I’ve been a big fan of Rhino Mocks and have often written about it glowingly. When Moq came on the scene, I remained blissfully ignorant...