Vb.net – Mocking VB.NET Methods With Moq

moqunit testingvb.net

I am trying to unit test a controller action that uses the membership provider to update user details. I am using Moq which so far has been easy to use.

The problem is I can't seem to get it to mock calls to methods that don't return anything.

<TestMethod()> _
Public Sub Can_Update_User()
  ' Arrange
  _membershipService.Setup(Function(x) x.UpdateUser(It.IsAny(Of MembershipUser)))
  Dim controller As New UsersController(_membershipService.Object, _roleProvider.Object, _supportWorksService.Object, _portalClientService.Object)
  ' Act
  Dim result As ViewResult = controller.Edit("testUser", New FormCollection)
  ' Assert
  Assert.AreEqual("Index", result.ViewName)
End Sub

The setup of the mocked membership service won't compile, the error is:

Overload resolution failed because no
accessible 'Setup' can be called with
these arguments:

'Public Function
Setup(Of TResult)(expression As
System.Linq.Expressions.Expression(Of
System.Func(Of
Services.IMembershipService,
TResult))) As
Moq.Language.Flow.ISetup(Of
Services.IMembershipService,
TResult)': Expression does not produce
a value.

'Public Function Setup(Of
TResult)(expression As
System.Linq.Expressions.Expression(Of
System.Func(Of
Services.IMembershipService,
TResult))) As
Moq.Language.Flow.ISetup(Of
Services.IMembershipService,
TResult)': Data type(s) of the type
parameter(s) cannot be inferred from
these arguments. Specifying the data
type(s) explicitly might correct this
error.

'Public Function
Setup(expression As
System.Linq.Expressions.Expression(Of
System.Action(Of
Services.IMembershipService))) As
Moq.Language.Flow.ISetup(Of
Services.IMembershipService)':
Expression does not produce a value.

What have I missed? Am I going to have to create a fake class rather than use Moq any time my class has a method I want to call on it?

Edit:

Ok, a little reading around suggests this is due to the way lambdas are expressed in VB using Function() which must have a result.

Has anyone found a work around for this or am I going to have to ditch Moq for faking methods?

Best Answer

In Visual Studio 2010 use

serviceMock.Setup(Sub(c) c.MethodName(paramName))

Also, make sure that the mocked entity (serviceMock) is either mocked as an interface, or has MethodName declared as overrideable.

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.

What’s the difference between faking, mocking, and stubbing

You can get some information :

From Martin Fowler about Mock and Stub

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

From xunitpattern:

Fake: We acquire or build a very lightweight implementation of the same functionality as provided by a component that the SUT depends on and instruct the SUT to use it instead of the real.

Stub : This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code (see Production Bugs on page X) within the SUT. A key indication for using a Test Stub is having Untested Code caused by the inability to control the indirect inputs of the SUT

Mock Object that implements the same interface as an object on which the SUT (System Under Test) depends. We can use a Mock Object as an observation point when we need to do Behavior Verification to avoid having an Untested Requirement (see Production Bugs on page X) caused by an inability to observe side-effects of invoking methods on the SUT.

Personally

I try to simplify by using : Mock and Stub. I use Mock when it's an object that returns a value that is set to the tested class. I use Stub to mimic an Interface or Abstract class to be tested. In fact, it doesn't really matter what you call it, they are all classes that aren't used in production, and are used as utility classes for testing.