3 reasons why I don't use strict mocks

Home

Source: own resources, Authors: Agnieszka and Michał Komorowscy

The majority, if not all, of mocking frameworks provides 2 types of mocks i.e. strict & loose. The difference between them is that the strict mocks will throw an exception if an unexpected (not configured /set up) method was called. I prefer to use loose mocks because with strict ones unit tests are fragile. Even the small change in the code can cause that unit tests will start failing. Secondly, if you need to set up many methods a test becomes less readable. Now, I can see one more reason.

Today, my colleague showed me a bug in my tests that were using strict mocks. He started investigation because we observed the following strange erros occuring during builds on the server:

System.Runtime.Serialization.SerializationException: Unable to find assembly 'Moq, Version=4.5.22.0, Culture=neutral, PublicKeyToken=69f491c39445e920'.

It was not easy to find a root cause because he couldn't reproduce a problem locally. However, finally he found what was wrong. The problem laid in the fact that some of classes being mocked were implementing IDisposable interface. It means that at some point of time the garbage colector was trying to dispose them. However, the strict mocks were not expecting calls to Dispose method so they were throwing exceptions.

If you want to reproduce a problem try the following simplified code.

using System;
using Moq;
using Moq.Protected;

namespace Sandbox
{
    class Program
    {
        static void Main(string[] args)
        {
            var mock = new Mock<BaseClass>(MockBehavior.Strict);

            //To fix a problem uncomment this line
            //mock.Protected().Setup("Dispose", ItExpr.IsAny<bool>());

            //If you call Dispose method directly in your code, then you also must setup the public Dispose method.
            //However, in this case the public Dispose method must be virtual because Moq can work only with virtual methods.
            //mock.Setup(x => x.Dispose());

            var obj = mock.Object;
        }
    }

    /// <summary>
    /// A model implementation of IDisposable interface
    /// https://msdn.microsoft.com/pl-pl/library/system.idisposable(v=vs.110).aspx
    /// </summary>
    public class BaseClass : IDisposable
    {
        private bool disposed = false;

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
            if (disposed) return;

            if (disposing) { /* ... */ }

            disposed = true;
        }

        ~BaseClass() { Dispose(false); }
    }
}

To sum up. The 3rd reason why I prefer loose mocks over strict ones is that sometimes it may be difficult to figure out which methods are actually used.