如何使用注入的依赖项对 .NET api 核心控制器进行单元测试，这些依赖项也与 MOQ 或 Fake 有依赖关系？答案

【问题标题】：How to unit test .NET api core controller with injected dependencies which also have dependencies with MOQ or Fake?如何使用注入的依赖项对 .NET api 核心控制器进行单元测试，这些依赖项也与 MOQ 或 Fake 有依赖关系？
【发布时间】：2019-02-19 13:37:39
【问题描述】：

我实现了一个 api 控制器，它将被另一个系统的一部分使用，而不是直接由用户使用。但是，我想为它提供一个单元测试。我开始查看最小起订量，然后我意识到我的特殊情况有点复杂。该代码有效，但正如我所说，我试图对其进行测试，而不（理想情况下）将任何数据写入 Db。

类的结构如下所示

api controller
    |__MyCustomClass (injected via startup along with configuration)
            |__UtilityClass (method: ImportSomeDataFromaFolder)
                |__MydataRepositoryClass
                    |__CustomDerivedDbContext
                        (override savechanges etc so as to capture EF errors)

注意：
- api方法的返回值是一个复杂的JSON对象。
- 我想要一个避免实际写入 Db 的测试
- 我正在创建一个自定义 DbContext (CustomDerivedContext) 并覆盖 savechanges，以便捕获通过列表更改的 EF 实体，例如。 List<EntityEntry>
- ImportSomeDataFromaFolder 方法，在将数据解析为 POCO 对象并将它们发送到 Repository 以持久保存到 Db 之后，然后将文件移动到不同的文件夹。在测试时，我宁愿这没有发生，而只是加载一个文件来解析。

需要测试 3 项主要内容：
(1) 文件中的数据是否被加载到 POCO 对象中
(2) POCO 对象是否正确转换为 EF 模型实体
(3) api是否返回包含预期结果的JSON对象

或者，我是否让事情变得比单元测试应该做的更复杂。我想针对 api 控制器编写一个测试，但它的 CustomDerivedDbContext 似乎我想在这里使用一个假的，因为我可以删除实际调用底层 DbContext 保存更改的步骤。

【问题讨论】：

听起来您与实现问题紧密耦合，这使得对您的主题进行孤立的单元测试很困难。这应该被视为代码异味，并表明当前的设计选择需要在可能的情况下进行审查和重构。如果对 API 控制器进行单元测试，那么理想情况下，您只需要模拟显式注入的抽象即可。 API 控制器不需要知道任何关于其依赖关系的依赖关系。

标签： unit-testing moq asp.net-core-webapi

【解决方案1】：

听起来您与实现问题紧密耦合，这使得孤立地测试您的主题变得困难。

这应该被视为代码异味，并表明当前的设计选择需要在可能的情况下进行审查和重构。

如果对 API 控制器进行单元测试，那么理想情况下，您只需要模拟显式注入的抽象即可。

如果遵循适当的关注点分离，API 控制器不需要了解其依赖项的依赖关系。

【讨论】：