我有一些 api 控制器方法，我想向其中添加一些单元测试。我正在使用 xunit 和 moq，并使用 asp net core 用 c# 编写。
一种方法的例子是：
public async Task<ActionResult<List<StatusDTO>>> Get()
{
return await _statusservice.GetStatusesAsync();
}
此时，我的控制器方法只是返回服务层方法正在返回的 dto。将来它可能会更改为返回特定的视图模型。
我已阅读https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/testing?view=aspnetcore-2.2以获取有关测试控制器的一些指导。
我的问题是：例如上面的单元测试是否只包括 - 检查返回类型ActionResult<StatusDTO>和/或（使用 moq）验证服务方法是否已被调用。
我应该设置我的服务方法来返回一个模拟StatusDTO并对此做一些断言。在这种情况下，我看不到这样做的好处，因为那将是测试服务方法，不是吗，我将在服务方法测试中介绍这一点。
对不起，如果这看起来很基本 - 我在编写单元测试方面的知识和经验非常有限。谢谢你的帮助。
一般来说，你不应该成为单元测试控制器。有警告，但因此是“一般”。例如，如果您有一些辅助方法，则对控制器的特定方法进行单元测试可能是合适的，但操作通常太复杂而无法进行可靠的单元测试。
这里有一个HttpContext，一个ActionContext，Session，User等-都需要通过模拟考试，以满足所有这些都可能会以不同的方式可能使用的所有的依赖和。当然，您可以模拟所有依赖项，但是当您完成此操作时，您的测试代码比实际应用程序代码长 100 倍，并且最终您的测试最终通过还是失败开始与是否有更多关系您已经正确地模拟了所有内容，而不是您的实际应用程序代码是否正确。
然后，特别是在这种情况下，您的操作只做一件事：调用服务类上的方法。服务类是应该进行单元测试的，假设它是经过联合测试的，那么为此操作添加单元测试不会增加任何内容。
总之，动作更适合集成测试。您应该将尽可能多的操作逻辑分解为可以单独进行单元测试（您已经完成）的方法或类，然后您只需测试集成，即特定请求会导致特定响应。
有关 ASP.NET Core 中集成测试的更多信息，请参阅相关文档。它更适合 Razor 页面，但无论您是集成测试 Razor 页面、MVC 操作还是 API 操作，方法都是相同的。这只是一个导致响应的请求。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句