3

我创建 Web API 已经有一段时间了，很高兴能够测试 CQRS 处理程序（由 Mediatr 管理）而不涉及任何类型的基础设施代码（控制器、请求等）。作为我的控制器，它完全有意义非常瘦，因为他们正在做控制器应该做的事情：请求和响应之间的通信：

    [HttpGet("requests")]
    public async Task<IEnumerable<AbsenceRequest>> GetAbsenceRequests(GetAbsenceRequests.Query query)
    {
        return await _mediator.Send(query);
    }

但仍有一些情况是我的 Handlers 测试没有涵盖的。这里有几个例子：

  1. 授权。我无法测试“错误”用户是否尝试访问特定操作，他收到拒绝访问错误。换句话说，我无法测试特定操作的授权属性。
  2. 错误处理。我可以检查我的处理程序是否在特定条件下引发了特定异常，但我无法控制基础设施（即异常中间件）如何处理此异常（即导致特定 HTTP 错误）。

ASP.NET Core 使请求输入响应输出集成测试变得非常容易（感谢 TestServer），我可以在集成测试中涵盖这两种情况。

困扰我的问题是我是否应该通过发送请求和断言响应来保持 Handlers 测试或测试操作。

我真的很喜欢 Handler 测试。它们很可爱，清晰且易于书写。测试整个请求更强大，但同时也更混乱，因为它是一种相对低级的方法，您必须处理 http 和 json。

我发现这个选择非常令人困惑，想知道推荐的方法是什么。

4

2 回答 2

8

我会使用单元测试来测试你的处理程序，因为这些测试可以运行得更快，并且应该比通过 MVC 测试处理程序更脆弱。没有充分的理由将处理程序的所有测试与当前的 MVC 实现结合起来。在决定是编写单元测试还是集成测试时，问题应该是“我可以用单元测试来测试吗？” 如果答案是肯定的，那就写一个单元测试。

现在，也就是说，使用 ASP.NET Core 中TestServer的集成测试非常棒（我在它们上面写了文档）。有些事情你不能用单元测试（你的处理程序或控制器操作方法）来测试，比如你的路由是否设置正确，或者你的 MVC 错误处理，或者过滤器，或者模型绑定。你应该编写测试来确认这种行为，使用集成测试和TestServer（如果你认为它们增加了价值，那就是）。你不应该测试你已经有单元测试的所有相同的场景——那将是一种浪费。但是您可以使用这种方法验证单元测试无法验证的不同内容。

于 2017-02-27T19:50:00.020 回答
0

保持测试是因为：“它们很可爱”我不会真正用作论据。

你为什么要测试？

  • 确保交付的软件能够正常工作（例如 NASA 飞船软件）
  • 减少事后修复错误的时间
  • 减少完成项目的时间

自动化测试很棒，因为它们可以始终如一地捕捉错误。但是，如果测试只是易于编写并且没有更多的好处，我会说它们是无用的，你应该删除它们。

另一方面，自动化单元测试肯定占有一席之地。因为他们在开发时发现了错误，因此修复起来最容易和最快。当您仅在发布时运行测试或只能在 ci build 中运行测试时，缺点是开发人员必须“再次”解决这个问题。

对于您作为经验丰富的软件工程师/项目负责人来说，决定什么对您的项目最有利。

于 2017-02-27T13:47:08.120 回答