C# – “Short circuiting” void methods with Moq

cmethodsmockingmoqunit testing

my team has made the decision recently to use Moq as our mocking framework for its tremendous flexibility and highly readable syntax. As we're new to it, I'm stumbling on what appears to be simple questions–searches (here, Google, etc.) find plenty of discussions on other nuances of Moq, but not necessarily what I'm after, and the few seemingly related questions have turned into red herrings.

We're testing a class that has an external dependency (Amazon SimpleDb to be precise) but don't want our tests bound to having a live connection out. A particular method:

Applies some "business" logic
If appropriate, invokes a call out to SDB via a provider we've built, let's call it SaveItem()

I want to unit test this such that we setup the context required and insure that SaveItem() was invoked, but in a manner that SaveItem() really isn't invoked (because A) the provider to SDB is a mock that isn't fully hydrated and will likely bomb and B) I don't want to have to pay for that transaction hundreds and thousands of times).

When dealing with methods that returned a value, this was trivial.

mockDb.Setup(d => d.GiveMeSomething()).Returns("Foo");

In the case that I outline above though, my "SaveItem()" method is void and therefore the option to use Moq's Returns() method isn't available. And while I can setup a callback to verify SaveItem() is invoked, I can't however seem to get it to not actually do anything.

Naive/hopeful, I thought the following would work, but it appears to still invoke the method:

mockDb.Setup(d => d.SaveItem(It.IsAny<object>()));

So the million dollar question: What's the Moq of the following fictitious code?

mockDb.Setup(d => d.SaveItem(It.IsAny<object>())).STOP_RIGHT_HERE();

Best Answer

If the SaveItem() method is virtual or abstract, and you're not setting Callbase = true, then the method should be re-implemented to do nothing by the mock.

You should be able to do:

mockDb.Setup(d => d.SaveItem(It.IsAny<object>())).Verifiable();

...  test here ...

mockDb.Verify();

Related Solutions

Java – How to test a class that has private methods, fields or inner classes

Update:

Some 10 years later perhaps the best way to test a private method, or any inaccessible member, is via @Jailbreak from the Manifold framework.
@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;
This way your code remains type-safe and readable. No design compromises, no overexposing methods and fields for the sake of tests.

If you have somewhat of a legacy Java application, and you're not allowed to change the visibility of your methods, the best way to test private methods is to use reflection.

Internally we're using helpers to get/set private and private static variables as well as invoke private and private static methods. The following patterns will let you do pretty much anything related to the private methods and fields. Of course, you can't change private static final variables through reflection.

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

And for fields:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

Notes:
1. TargetClass.getDeclaredMethod(methodName, argClasses) lets you look into private methods. The same thing applies for getDeclaredField.
2. The setAccessible(true) is required to play around with privates.

C# – How to verify that method was NOT called in Moq

Run a verify after the test which has a Times.Never enum set. e.g.

_mock.Object.DoSomething()
_mock.Verify(service => service.ShouldntBeCalled(), Times.Never);

Best Answer

Related Solutions

Java – How to test a class that has private methods, fields or inner classes

C# – How to verify that method was NOT called in Moq

Related Topic