没有TestServer的AspNet Core集成测试

Question

我们有一个现有的ASP.NET Web Api 2应用程序，正在迁移到ASP.NET核心MVC。至此，该应用程序已正常运行，但我们尚未迁移所有测试。我们当前的测试以以下方式工作，所有这些步骤都针对每个测试执行：

设置（在所有测试中都很常见）

• 初始化本地基础结构（内存数据库等）。
• 设置与生产相关的DI容器，但与外界进行通信的组件除外，但允许每个测试类通过覆盖一个简单的方法来注入自己的测试双打。
• 通过从DI容器解析对象来设置被测对象（始终是控制器）。

测试

• 安排：将测试数据插入本地数据库，准备控制器操作参数，设置存根数据。...
• 操作：调用控制器操作。
• 声明：检查HttpResponseMessage的状态（状态代码...）和返回的对象（使用自定义帮助程序反序列化），检查模拟/间谍期望值和/或本地数据库状态。

拆卸（在所有测试中都很常见）

• 清理本地基础结构。

如您所见，我们的测试比integration tests更接近unit tests，因为我们始终使用接近完整的依赖图。但是我们不需要使用测试服务器，并且可以在执行之前直接对控制器的状态进行操作（设置当前用户等）。

与集成测试（在不到一分钟的时间内执行数百个测试）相比，这将导致执行时间非常快，并且对子层重构具有极大的弹性（当服务提供服务时，我们不需要重写数十个测试）接受新的依存关系，或分为两个部分）。唯一的缺点是过滤器和中间件的短路，我们必须单独测试。

ASP.NET Core MVC似乎无法使这种方法成为可能或变得简单（甚至不建议使用）。

• 我们应该将测试转换为集成测试，并使用内置的测试服务器吗？这将如何影响性能（开发人员经常用于运行整个测试集）？
• 我们是否应该重写95％的测试并坚持使用Microsoft的单元测试方法（以最小的深度进行单个公共方法测试），而在单独的项目中仅保留几个集成测试？
• 在我们的初始方法附近是否还有其他选择，允许我们在每个测试之前从DI容器解析控制器并设置其HTTP上下文？如果可能的话，也许我们可以至少暂时使用这种方法。