如何用MOQ/Fake对含多层依赖的.NET Core API控制器做单元测试

先给你吃个定心丸：你想测试的三个点都是单元测试的核心场景，而且通过分层隔离依赖的方式，完全可以把复杂的链路拆成简单的小测试，不用纠结“是不是把测试搞复杂了”。咱们一步步来拆解：

一、拆分测试点，聚焦单一职责 #

单元测试的核心是“只测当前类/方法的逻辑”，所以不用一次性把API控制器→MyCustomClass→仓储→DbContext的整条链路都测一遍。把你的三个需求拆成独立的测试场景，每个场景只关注一个环节：

1. 测试「文件→POCO」的解析逻辑 #

这部分直接测UtilityClass的ImportSomeDataFromaFolder方法就行，但要先把文件移动的逻辑抽离出来（如果现在是和解析写在一起的话）。比如新增一个IFileMover接口：

public interface IFileMover
{
    void MoveProcessedFile(string sourcePath, string targetPath);
}

然后让UtilityClass依赖这个接口，原来的文件移动逻辑改成调用IFileMover.MoveProcessedFile。

测试时，用Moq创建一个Mock的IFileMover，让它什么都不做：

var mockFileMover = new Mock<IFileMover>();
mockFileMover.Setup(m => m.MoveProcessedFile(It.IsAny<string>(), It.IsAny<string>()))
             .Verifiable();

var utility = new UtilityClass(mockFileMover.Object);
var testFilePath = Path.Combine(TestContext.TestDeploymentDir, "test-data.txt"); // 测试用的样本文件

// 调用解析方法
var pocoList = utility.ImportSomeDataFromaFolder(testFilePath);

// 验证解析结果：对比POCO的属性和预期值
Assert.Equal("预期值", pocoList[0].SomeProperty);
// 可选：验证文件移动方法被调用（如果需要确认流程走到这一步）
mockFileMover.Verify(m => m.MoveProcessedFile(testFilePath, It.IsAny<string>()), Times.Once);

这样就完全隔离了文件系统的修改，只测解析逻辑。

2. 测试「POCO→EF实体」的转换逻辑 #

如果转换逻辑是写在MyCustomClass里，建议把它抽成独立的IModelMapper接口：

public interface IModelMapper
{
    MyEntity MapPocoToEntity(PocoModel poco);
}

然后让MyCustomClass依赖这个接口。测试时直接测IModelMapper的实现：

var mapper = new ModelMapper(); // 你的转换类
var testPoco = new PocoModel { /* 填充测试数据 */ };

var entity = mapper.MapPocoToEntity(testPoco);

// 验证实体属性是否和POCO对应
Assert.Equal(testPoco.Id, entity.EntityId);
Assert.Equal(testPoco.Name, entity.EntityName);
// ...其他属性验证

这部分完全不需要涉及仓储或DbContext，就是纯对象转换的测试，非常简单。

3. 测试API返回的JSON是否符合预期 #

这部分测API控制器，只需要Mock掉MyCustomClass的依赖，让它返回预设的结果，然后验证控制器的返回值：

// Mock MyCustomClass，让它返回你预设的复杂对象
var mockCustomClass = new Mock<MyCustomClass>(MockBehavior.Default, /* 它的依赖，比如mock的IModelMapper、IRepository等 */);
mockCustomClass.Setup(c => c.YourApiMethodLogic(It.IsAny<string>()))
               .Returns(new ComplexApiResponse { /* 填充预期的返回数据 */ });

// 初始化控制器
var controller = new YourApiController(mockCustomClass.Object);
// 调用API方法
var result = controller.YourApiAction("test-folder-path") as OkObjectResult;

// 验证返回结果
Assert.NotNull(result);
var response = result.Value as ComplexApiResponse;
Assert.Equal("预期的JSON字段值", response.SomeProperty);
// 如果需要验证JSON结构，可以序列化后对比字符串
var serializedResponse = JsonSerializer.Serialize(response);
Assert.Equal(expectedJsonString, serializedResponse);

这样就完全隔离了底层的仓储、DbContext，只测控制器的逻辑是否正确返回预期的对象（进而对应正确的JSON）。

二、用Fake DbContext跳过数据库写入 #

如果你需要测试仓储层的逻辑（比如验证仓储是否正确调用了Add/Update方法），可以自己写一个Fake的CustomDerivedDbContext，或者用Moq模拟DbSet和SaveChanges：

方案1：手写Fake DbContext #

先给CustomDerivedDbContext抽象一个接口ICustomDbContext，包含需要的DbSet和SaveChanges方法：

public interface ICustomDbContext
{
    DbSet<MyEntity> MyEntities { get; set; }
    int SaveChanges();
}

public class CustomDerivedDbContext : DbContext, ICustomDbContext
{
    // 原来的实现...
}

然后写Fake实现，用内存集合模拟DbSet：

public class FakeCustomDbContext : ICustomDbContext
{
    private readonly List<MyEntity> _myEntities = new();
    public DbSet<MyEntity> MyEntities { get; set; }

    public FakeCustomDbContext()
    {
        // 用InMemory的DbSet实现，或者用Moq创建Mock<DbSet<MyEntity>>
        MyEntities = new Mock<DbSet<MyEntity>>().Object;
    }

    public int SaveChanges()
    {
        // 不实际写入数据库，只返回模拟的受影响行数
        return _myEntities.Count;
    }

    // 如果需要跟踪变更，可以自己维护List<EntityEntry>
    public IEnumerable<EntityEntry> GetChangedEntities()
    {
        // 返回模拟的变更实体
        return _myEntities.Select(e => new Mock<EntityEntry>().Object);
    }
}

测试仓储时注入FakeCustomDbContext，就不会写入真实数据库了。

方案2：用Moq模拟DbContext #

如果不想手写Fake，可以直接用Moq模拟DbSet和SaveChanges：

// 模拟DbSet
var mockDbSet = new Mock<DbSet<MyEntity>>();
// 模拟DbContext
var mockContext = new Mock<ICustomDbContext>();
mockContext.Setup(c => c.MyEntities).Returns(mockDbSet.Object);
mockContext.Setup(c => c.SaveChanges()).Returns(1); // 模拟保存成功

// 初始化仓储
var repository = new MydataRepositoryClass(mockContext.Object);
// 调用仓储方法
repository.AddEntity(new MyEntity());

// 验证仓储是否正确调用了DbSet.Add
mockDbSet.Verify(d => d.Add(It.IsAny<MyEntity>()), Times.Once);
// 验证SaveChanges被调用
mockContext.Verify(c => c.SaveChanges(), Times.Once);

三、关于“测试是否复杂化”的疑惑 #

你并没有把测试搞复杂，反而你的需求是典型的“依赖隔离”单元测试场景。之所以觉得复杂，大概率是因为原来的代码耦合度有点高（比如一个类同时负责解析、转换、调用仓储）。

解决办法就是把大职责拆成小接口：比如把文件解析、对象转换、文件移动、数据持久化分别抽象成独立的接口，这样每个类的职责单一，测试时只需要Mock对应的接口即可，每个测试都会非常清晰。

总结下来：你的三个测试点都可以通过分层隔离的方式轻松实现，而且测试代码会很简洁。关键是先梳理代码的依赖链，把可替换的部分抽象成接口，这样Mock/Fake起来就非常方便了。

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