Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Moq

Re-usable Mocks in .NET using Moq

0.00/5 (No votes)
5 Aug 2023CPOL2 min read 3K  
Common practice that I employ in test projects - re-usable mocks

A while ago, I wrote a small example of using the Builder pattern in automated tests, and I wanted to follow it up with another common practice that I employ in test projects - re-usable mocks.

Image 1

What are Mocks Again?

For those of you who might be new-ish to automated tests, imagine you’ve got a class that looks something like this:

C#
public class Mailer
{
    private readonly ISmtpClient _smtpClient;

    public Mailer(ISmtpClient smtpClient)
    {
        _smtpClient = smtpClient;
    }

    public async Task SendMailAsync(SendMailRequest request)
    {
        await _smtpClient.SendAsync(new SmtpMessage()
        {
            Port = 25,
            To = request.To,
            Credentials = CredentialsFactory.GetSmtpCredentials(),
            // ...
        });
    }
}

Note: The above code is an imaginary sample. These classes don’t actually exist.

If we wanted to create an isolated test for this, that doesn’t actually send any emails (i.e.,a unit test), then we need a way of creating a fake instance of ISmtpClient that we control, which doesn’t actually send any mail, but allows us to inspect when methods get called, provide dummy data, etc. That’s basically a mock.

Writing Mocks with…Moq

If we then wanted to create a unit test (with mocks) for the above mailer class, it might look something like this:

C#
public class MailerTests
{
    [Fact]
    public async Task Can_send_mail()
    {
        // Arrange
        var smtp = new Mock<ISmtpClient>();
        smtp.Setup(m => m.SendAsync(It.IsAny<SmtpRequest>())).Verifiable();

        // Act
        var sut = new Mailer(smtp.Object);
        await sut.SendMailAsync(new SendMailRequest()
        {
            // 
        });

        // Assert
        smtp.Verify(); // this will throw if SendAsync was not called
    }
}

In short, we create a mock of ISmtpClient called smtp, set it up so that it mocks the SendAsync method and mark it as verifiable - so that we can verify if it was called later. We pass the mock into the Mailer (the service under test) and then verify later that the method was called.

Sounds Good! What’s Wrong with This?

I wouldn’t say that anything is wrong with it - but it can be made more reusable. Let’s just say that we had a couple of other tests (and potentially other services, which all have their own tests, too) that all use the ISmtpClient. We’d have to repeat this process of creating a mock every time. Whereas instead, we could do this:

C#
public class MockSmtpClient : IMock<SmtpClient>
{
    public MockSmtpClient SetupSendAsync(bool veriable = false)
    {
        var setup = Setup(m => m.SendAsync(It.IsAny<SmtpRequest>()));

        if (verifiable)
            setup.Verifiable();

        return this;
    }
}

The idea is that now we have a re-usable mock that we can use across multiple tests. Especially when the service that you’re mocking contains a number of methods that will be used (think repositories and other data-related services), this can make the test code a lot more concise and readable. It also means that if you ever want to change how all your mocks are setup (e.g.: to make them all verifable), you should have far fewer places to change than trying to change every instance of Mock<T>.

Anyway - that about wraps it up. Does anyone follow a similar practice, or have any other common practices when it comes to automated tests? Let me know in the comments!

Catch ya!

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)