我应该在 Web Api Core 中测试 CQRS 处理程序还是整个请求输出

Question

我创建 Web API 已经有一段时间了，很高兴能够测试 CQRS 处理程序（使用 Mediatr 管理），而无需触及任何类型的基础架构代码（控制器、请求等） .这完全有意义，因为我的控制器非常薄，因为它们正在做控制器应该做的事情：在请求和响应之间进行通信：

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

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

授权。我无法测试 "wrong" 用户是否尝试访问具体操作，他收到拒绝访问错误。换句话说，我无法测试特定操作的授权属性。
错误处理。我可以检查我的处理程序是否抛出了一个特定的特定条件下的异常，但我无法控制如何基础设施（即异常中间件）处理了这个异常（即导致特定的 HTTP 错误）。

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

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

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

我觉得这个选择很混乱，想知道推荐的方法是什么。

Answer 1

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

你为什么要考试？

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

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

另一方面，自动化单元测试肯定有一席之地。由于它们在开发时发现错误，因此最容易和最快地修复。当您运行您的测试仅在发布时或仅可能在 ci 构建时，缺点是开发人员必须解决问题 'again'.

对于作为经验丰富的软件 engineer/Project 领导者的您来说，就是要确定ci什么对您的项目最有益。

Answer 2

我会使用单元测试来测试您的处理程序，因为与通过 MVC 测试处理程序相比，这些测试可以运行更快并且应该不那么脆弱。没有充分的理由将处理程序的所有测试耦合到当前的 MVC 实现。在决定是写单元测试还是集成测试时，问题应该是 "Can I test this with a unit test?" 如果答案是肯定的，那么写单元测试。

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

我应该在 Web Api Core 中测试 CQRS 处理程序还是整个请求输出

Should I test CQRS Handlers or the whole request output in Web Api Core

.net

asp.net-web-api

asp.net-core

cqrs

mediatr