What can we Moq?

The most popular and friendly mocking library for .NET

Photo by Austin Distel on Unsplash

Many times when we want to test a component in a unit test, this component uses objects that are its dependency. Mock objects are used for testing as a replacement for real implementation. We can configure different behaviors to the mock objects, and that way we can test the component to handle all behaviors correctly.

What can we mock?

We can think about a mock as an instance of dynamically created type, that implements the interface. The mock object can also be an instance that inherits from the class and has the ability to override the virtual methods of this class, and implement its abstract methods.

This is why we can’t test cases where the test depends on a private or static method (at least there is not a simple way to do it). In case of static methods, we can solve it using a wrapper as suggested here .

Mocking interface methods and properties:

In this example we have an interface IEmailValidator with a property containing a list of strings, and a method to validate the email address. UserController uses this interface when updating the user’s email.

When we want to test the controller’s UpdateEmail method, we need to mock the IEmailValidator. SetUpGet is the way to configure the returned property value of this interface (line 8), and in line 9 you can see how to configure the returned value when calling Validate method:

Mocking abstract and virtual methods:

Here we have an example of how we can mock an object that inherits from an abstract class that has both a virtual method, and an abstract method. An abstract method is a method that needs to be implemented by the sub class. A virtual method is a method that has an implementation by the abstract class, but the sub class can always override this implementation.

In this example the sub class (TextFileReader) doesn’t override the abstract class implementation. When mocking TextFileReader, you can see that there are two options of how to configure the virtual method:

1. Setup a new return value, as described in line 2.
2. Using the CallBase(), which configures the mock to use the implemented behavior that already exists for the class by its parent class (line 6). This is right for every virtual method, whether it’s implemented in an abstract class or a regular class.

The configuration of an abstract method is the same as we have in interfaces.

Mocking protected methods:

In this example, we have a class that uses a HttpClient. When we want to test GetCarPrice method, we need to find a way to mock HttpClient - as this method has dependency on HttpClient.

Unfortunately we can’t mock its GetAsync method, as HttpClient is not an interface, and this method is not abstract nor virtual.

Moq.Protected namespace give us the ability to mock protected methods. Protected() just gives you access (presumably through reflection, since it’s string-based) to override protected members.

HttpClient has a dependency on HttpMessageHandler. Whenever GetAsync method is called, it goes through the HttpMessageHandler’s SendAsync method. This is a protected method, therefore we can mock it. We can inject the mocked HttpMessageHandler to the HttpClient, and by that mocking the returned value of GetAsync method.

So keep on mocking with Moq 😃