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?

Answer 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.

Answer 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)); }