为什么要编写控制器的单元测试？

对我来说，这是完全不相关的单元测试，我不明白为什么有人会花时间编写它，因为从中获得的价值很小。如果此控制器通过在浏览器中执行该方法返回所需的类型，我会非常清楚。确实，您认为需要为此进行测试吗？为什么？

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}

他们的关键点在这里：

如果此控制器通过在浏览器中执行方法返回所需的类型，我会非常清楚

单元测试是关于自动化非回归测试简单的代码单元，而不是您自己看。您不想总是在应用程序中进行单元设置。

编辑：添加@anotherdave评论：

这与扩展的难易程度有关。在浏览器中测试一个控制器可能没问题；10、20、50个控制器呢？您只需编写一次测试；更换控制器时可能需要更新它，这是开销。但是，您多久部署一次？当然，每次进行检查时，手动检查的开销都要大得多

作为@Vladislav答案的替代方法，对所有内容进行单元测试绝对是过大的，并且确实是不受欢迎的。如果您需要更轻的东西，可以使用Selenium进行更高级别的非回归测试。当然，您获得的覆盖范围比单元测试要少，但是您可以获得合理的覆盖范围，从而减少了进行单元测试的时间，并且更加灵活。

也就是说，如果您对所有内容进行单元测试，则每次修改一个简单元素时都必须更新一个或多个测试。

为什么要编写控制器的单元测试？

因为在不了解上下文的情况下无法确定是否需要测试。以下是一些您可能要测试控制器的原因：

• 控制器可能包含复杂的服务接线逻辑，容易出错。服务本身可能运行良好，这是您要测试的结果，并且出于某些原因，您考虑不将业务流程层引入应用程序中
• 您的控制器包含应用程序的全部业务逻辑，并且实际上您可以测试所有控制器（请不要假装自己一生都在使用理想的代码库，请相信我）
• 您的团队由99％的天才和1％的平均水平的人组成，并且您希望将这1％的薪水中的错误排除在外

我完全同意OP。

控制器的单元测试毫无意义。您可以通过回归测试隐式测试控制器（例如，使用Selenium）。

您应该TDD控制器使用的所有组件/对象，并使控制器尽可能地薄。然后，所有内容均经过正确的单元测试。您想确定的是，在执行Web请求时，一切都可以很好地协同工作。那就是回归测试。