MVC EF Core仓储模式CRUD单元测试：内存库还是Mock？

问题描述 #

我是测试新手，目前工作中需要用MSTest给自己编写的MVC EF Core仓储层写简单的CRUD单元测试。其中一个查询方法用了Include做贪婪加载，其余都是基础CRUD操作。现在纠结到底该用内存数据库，还是Mock EF Core的DbContext和DbSet？想知道这个场景下的最佳实践是什么？

相关代码 #

public DbSet<ResourceTags>? ResourceTags { get; set; }

public class ResourceTags
{
    [ForeignKey(nameof(ResourceRequest))]
    [Key]
    [Column(Order = 0)]
    public byte[] ResourceId { get; set; }

    [Key]
    [Column(Order = 1)]
    public string Tag { get; set; }

    public ResourceRequest ResourceRequest { get; set; }
}

public ResourceTags? AddResourceTags(ResourceTags resourceTag)
{
    try
    {
        var entity = this.prismContext.ResourceTags;

        if (entity != null)
        {
            var response = entity.Add(resourceTag);
            this.prismContext.SaveChanges();
            return response.Entity;
        }
    }
    catch
    {
        throw new Exception();
    }

    return null;
}

// 原Mock方式的测试方法
[TestMethod]
public void AddResourceTagsSavesAResourceTagsViaContext()
{
    Random rnd = new Random();
    var id = new byte[32];
    rnd.NextBytes(id);
    var text = "tagtext";
    string convertedId = Convert.ToBase64String(id);

    var mockResourceTag = new Mock<DbSet<ResourceTags>>();
    var mockPrismContext = new Mock<PrismContext>();

    mockPrismContext.Setup(m => m.ResourceTags).Returns(mockResourceTag.Object);

    var azureRepository = new AzureRepository(mockPrismContext.Object);
    var tag = new ResourceTags()
    {
        ResourceId = id,
        Tag = text,
    };

    var response = azureRepository.AddResourceTags(tag);
    Assert.IsNotNull(response);
}

最佳方案分析 #

两种方式的优劣势对比 #

Mock DbContext/DbSet

• 优点：测试速度极快，仅聚焦仓储层的逻辑调用（比如是否调用了Add、SaveChanges），无需关心EF Core的内部行为。适合纯验证方法调用的简单场景。
• 缺点：难以模拟Include这类EF Core专属的查询扩展方法，Mock配置复杂且容易和真实运行行为脱节，尤其涉及导航属性、实体状态跟踪时，Mock的成本会急剧上升。

EF Core内存数据库（InMemory Provider）

• 优点：完全模拟EF Core的真实运行逻辑，支持Include、导航属性加载、实体状态管理等所有EF特性，测试结果更贴近生产环境。配置简单，无需复杂Mock，直接使用真实的DbContext连接内存数据库即可。
• 缺点：相比Mock速度略慢，但对于单元测试来说，这点差异几乎可以忽略。

针对你的场景的结论 #

因为你存在带Include的查询方法，Mock这类操作不仅配置繁琐，还容易出现“测试通过但实际运行出错”的情况。因此优先选择内存数据库作为单元测试的方案：

1. 对于基础CRUD操作，内存数据库能准确验证实体是否被正确持久化，SaveChanges是否生效。
2. 对于带Include的查询，内存数据库可以真实加载关联实体，确保查询逻辑的正确性。

内存数据库版测试示例 #

替换原Mock测试，用内存数据库实现更可靠的测试：

[TestMethod]
public void AddResourceTags_SavesResourceTagSuccessfully()
{
    // 配置内存数据库，每个测试用独立的数据库名避免干扰
    var options = new DbContextOptionsBuilder<PrismContext>()
        .UseInMemoryDatabase(databaseName: $"Test_AddResourceTags_{Guid.NewGuid()}")
        .Options;

    // 创建内存数据库上下文
    using var context = new PrismContext(options);
    var repository = new AzureRepository(context);

    // 准备测试数据
    var rnd = new Random();
    var resourceId = new byte[32];
    rnd.NextBytes(resourceId);
    var testTag = new ResourceTags
    {
        ResourceId = resourceId,
        Tag = "tagtext"
    };

    // 执行仓储方法
    var result = repository.AddResourceTags(testTag);

    // 验证返回结果
    Assert.IsNotNull(result);
    Assert.IsTrue(testTag.ResourceId.SequenceEqual(result.ResourceId));
    Assert.AreEqual(testTag.Tag, result.Tag);

    // 验证数据库中确实存在该实体
    var savedTag = context.ResourceTags.FirstOrDefault(t => 
        t.ResourceId.SequenceEqual(resourceId) && t.Tag == "tagtext");
    Assert.IsNotNull(savedTag);
}

额外提示 #

• 内存数据库是轻量级的，建议每个测试使用唯一的数据库名（比如拼接Guid），避免不同测试之间的数据干扰。
• 如果后续仓储层涉及更复杂的EF查询（如过滤、排序、分组），内存数据库依然能提供可靠的测试支持。
• 仅当你完全不需要验证EF的查询/持久化行为，只需要确认仓储层是否调用了特定方法时，才考虑使用Mock方式。

内容的提问来源于stack exchange，提问作者Tim Whatley