Mock IMemoryCache in unit test

Question

I am using asp net core 1.0 and xunit.

I am trying to write a unit test for some code that uses IMemoryCache. However whenever I try to set a value in the IMemoryCache I get an Null reference error.

My unit test code is like this:
The IMemoryCache is injected into the class I want to test. However when I try to set a value in the cache in the test I get a null reference.

public Test GetSystemUnderTest()
{
    var mockCache = new Mock<IMemoryCache>();

    return new Test(mockCache.Object);
}

[Fact]
public void TestCache()
{
    var sut = GetSystemUnderTest();

    sut.SetCache("key", "value"); //NULL Reference thrown here
}

And this is the class Test...

public class Test
{
    private readonly IMemoryCache _memoryCache;
    public Test(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache;
    }

    public void SetCache(string key, string value)
    {
        _memoryCache.Set(key, value, new MemoryCacheEntryOptions {SlidingExpiration = TimeSpan.FromHours(1)});
    }
}

My question is...Do I need to setup the IMemoryCache somehow? Set a value for the DefaultValue? When IMemoryCache is Mocked what is the default value?

Solution 1

IMemoryCache.Set Is an extension method and thus cannot be mocked using Moq framework.

The code for the extension though is available here

public static TItem Set<TItem>(this IMemoryCache cache, object key, TItem value, MemoryCacheEntryOptions options)
{
    using (var entry = cache.CreateEntry(key))
    {
        if (options != null)
        {
            entry.SetOptions(options);
        }

        entry.Value = value;
    }

    return value;
}

For the test, a safe path would need to be mocked through the extension method to allow it to flow to completion. Within Set it also calls extension methods on the cache entry, so that will also have to be catered for. This can get complicated very quickly so I would suggest using a concrete implementation

//...
using Microsoft.Extensions.Caching.Memory;
using Microsoft.Extensions.DependencyInjection;
//...

public Test GetSystemUnderTest() {
    var services = new ServiceCollection();
    services.AddMemoryCache();
    var serviceProvider = services.BuildServiceProvider();

    var memoryCache = serviceProvider.GetService<IMemoryCache>();
    return new Test(memoryCache);
}

[Fact]
public void TestCache() {
    //Arrange
    var sut = GetSystemUnderTest();

    //Act
    sut.SetCache("key", "value");

    //Assert
    //...
}

So now you have access to a fully functional memory cache.

Solution 2

TLDR

Scroll down to the code snippet to mock the cache setter indirectly (with a different expiry property)

/TLDR

While it's true that extension methods can't be mocked directly using Moq or most other mocking frameworks, often they can be mocked indirectly - and this is certainly the case for those built around IMemoryCache

As I have pointed out in this answer, fundamentally, all of the extension methods call one of the three interface methods somewhere in their execution.

Nkosi's answer raises very valid points: it can get complicated very quickly and you can use a concrete implementation to test things. This is a perfectly valid approach to use. However, strictly speaking, if you go down this path, your tests will depend on the implementation of third party code. In theory, it's possible that changes to this will break your test(s) - in this situation, this is highly unlikely to happen because the caching repository has been archived.

Furthermore there is the possibility that using a concrete implementation with a bunch of dependencies might involve a lot of overheads. If you're creating a clean set of dependencies each time and you have many tests this could add quite a load to your build server (I'm not saying that that's the case here, it would depend on a number of factors)

Finally you lose one other benefit: by investigating the source code yourself in order to mock the right things, you're more likely to learn about how the library you're using works. Consequently, you might learn how to use it better and you will almost certainly learn other things.

For the extension method you are calling, you should only need three setup calls with callbacks to assert on the invocation arguments. This might not be appropriate for you, depending on what you're trying to test.

[Fact]
public void TestMethod()
{
    var expectedKey = "expectedKey";
    var expectedValue = "expectedValue";
    var expectedMilliseconds = 100;
    var mockCache = new Mock<IMemoryCache>();
    var mockCacheEntry = new Mock<ICacheEntry>();

    string? keyPayload = null;
    mockCache
        .Setup(mc => mc.CreateEntry(It.IsAny<object>()))
        .Callback((object k) => keyPayload = (string)k)
        .Returns(mockCacheEntry.Object); // this should address your null reference exception

    object? valuePayload = null;
    mockCacheEntry
        .SetupSet(mce => mce.Value = It.IsAny<object>())
        .Callback<object>(v => valuePayload = v);

    TimeSpan? expirationPayload = null;
    mockCacheEntry
        .SetupSet(mce => mce.AbsoluteExpirationRelativeToNow = It.IsAny<TimeSpan?>())
        .Callback<TimeSpan?>(dto => expirationPayload = dto);

    // Act
    var success = _target.SetCacheValue(expectedKey, expectedValue,
        new MemoryCacheEntryOptions().SetAbsoluteExpiration(TimeSpan.FromMilliseconds(expectedMilliseconds)));

    // Assert
    Assert.True(success);
    Assert.Equal("key", keyPayload);
    Assert.Equal("expectedValue", valuePayload as string);
    Assert.Equal(expirationPayload, TimeSpan.FromMilliseconds(expectedMilliseconds));
}

Solution 3

I had a similar issue but I want to disable caching for debugging occasionally as its a pain to keep having to clear the cache. Just mock/fake them yourself (using StructureMap dependency injection).

You could easily use them in you tests as well.

public class DefaultRegistry: Registry
{
    public static IConfiguration Configuration = new ConfigurationBuilder()
        .SetBasePath(HttpRuntime.AppDomainAppPath)
        .AddJsonFile("appsettings.json")
        .Build();

    public DefaultRegistry()
    {
        For<IConfiguration>().Use(() => Configuration);  

#if DEBUG && DISABLE_CACHE <-- compiler directives
        For<IMemoryCache>().Use(
            () => new MemoryCacheFake()
        ).Singleton();
#else
        var memoryCacheOptions = new MemoryCacheOptions();
        For<IMemoryCache>().Use(
            () => new MemoryCache(Options.Create(memoryCacheOptions))
        ).Singleton();
#endif
        For<SKiNDbContext>().Use(() => new SKiNDbContextFactory().CreateDbContext(Configuration));

        Scan(scan =>
        {
            scan.TheCallingAssembly();
            scan.WithDefaultConventions();
            scan.LookForRegistries();
        });
    }
}

public class MemoryCacheFake : IMemoryCache
{
    public ICacheEntry CreateEntry(object key)
    {
        return new CacheEntryFake { Key = key };
    }

    public void Dispose()
    {

    }

    public void Remove(object key)
    {

    }

    public bool TryGetValue(object key, out object value)
    {
        value = null;
        return false;
    }
}

public class CacheEntryFake : ICacheEntry
{
    public object Key {get; set;}

    public object Value { get; set; }
    public DateTimeOffset? AbsoluteExpiration { get; set; }
    public TimeSpan? AbsoluteExpirationRelativeToNow { get; set; }
    public TimeSpan? SlidingExpiration { get; set; }

    public IList<IChangeToken> ExpirationTokens { get; set; }

    public IList<PostEvictionCallbackRegistration> PostEvictionCallbacks { get; set; }

    public CacheItemPriority Priority { get; set; }
    public long? Size { get; set; }

    public void Dispose()
    {

    }
}

Solution 4

I also came across this problem in a .Net 5 project and I solved it by wrapping the memory cache and only exposing the functionality that I need. This way I conform to the ISP and it's easier to work with my unit tests.

I created an interface

public interface IMemoryCacheWrapper
{
    bool TryGetValue<T>(string Key, out T cache);
    void Set<T>(string key, T cache);
}

Implemented the memory cache logic in my wrapper class, using MS dependency injection, so I'm not reliant on those implementation details in my class under test, plus it has the added benefit of adhering to the SRP.

public class MemoryCacheWrapper : IMemoryCacheWrapper
{
    private readonly IMemoryCache _memoryCache;

    public MemoryCacheWrapper(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache;
    }

    public void Set<T>(string key, T cache)
    {
        _memoryCache.Set(key, cache);
    }

    public bool TryGetValue<T>(string Key, out T cache)
    {
        if (_memoryCache.TryGetValue(Key, out T cachedItem))
        {
            cache = cachedItem;
            return true;
        }
        cache = default(T);
        return false;
    }
}

I added my memory cache wrapper to the dependency injection and I replaced the system memory cache in my code with the wrapper and that is what I mock out in my tests. All in all a relatively quick job and I think a better structure too.

In my test I then added this so that it mimics the cache updating.

        _memoryCacheWrapperMock = new Mock<IMemoryCacheWrapper>();
        _memoryCacheWrapperMock.Setup(s => s.Set(It.IsAny<string>(), It.IsAny<IEnumerable<IClientSettingsDto>>()))
            .Callback<string, IEnumerable<IClientSettingsDto>>((key, cache) =>
            {
                _memoryCacheWrapperMock.Setup(s => s.TryGetValue(key, out cache))
                    .Returns(true);
            });

View more solutions

Comments

[TTCG]

Which library do I need to call Mock<Object> method?

[Nkosi]

@TTCG check out the Moq library - Github, nuget

[Ask]

@Nkosi, can you tell me how to create mock of IDistributedCache?

[Nkosi]

@Ask for testing and development purposes you can use services.AddDistributedMemoryCache(); instead. Reference docs.microsoft.com/en-us/aspnet/core/performance/caching/…

[Martijn]

Tried this in Core 3.1, but getting error "'IServiceCollection' does not contain a definition for 'AddMemoryCahce' and no accessible extenstion method'...". Anyone have a way to unit test methods that use IMemoryCache's extension methods?

[Hanno]

I was about to post something similar to this, but than I saw your answer which is much more extensive. For me it was enough to mock the CreateEntry method on IMemoryCache with mockCacheEntry.Object. That solves a NullReferenceException that would otherwise be thrown when calling the Set extension method.

[Jhonny D. Cano -Leftware-]

TryGetValue is also an extension method from Microsoft.Extensions.Caching.Memory.CacheExtensions. Maybe the overload you are talking about is TryGetValue(object key, out object value)

[NavidM]

Instead of creating a new ServiceCollection and doing all of the dependency injection stuff you can just mock out the IOptions<MemoryCacheOptions> and make sure that it returns a new instance of MemoryCacheOptions that contains a SystemClock object. Here is a code snippet (note that I'm using NSubstitute instead of moq): var cacheOptions = Substitute.For<IOptions<MemoryCacheOptions>>(); cacheOptions.Value.Returns(new MemoryCacheOptions() { Clock = new SystemClock() }); var cache = new MemoryCache(cacheOptions); // you can use this.