如何对控制器方法的 HandleError 属性的行为进行单元测试？

Question

我正在尝试验证 ASP.Net MVC 应用程序在发生意外错误时的行为。 具体来说，我试图验证用户是否被定向到我为我的应用程序定义的错误页面。 我遇到的问题是我无法按预期验证控制器方法的行为。

对于我的正常行为测试，我创建一个模拟业务规则对象并将其传递给我的控制器，然后从我想要测试的控制器方法验证 ViewResult。 当事情按预期进行时，这对我的目的来说效果很好。 但是，当我从业务规则方法抛出异常时，该异常将通过控制器方法结果进行处理，而不是被处理（控制器方法具有“HandleError”属性）由控制器执行，以便返回适合我的错误页面的 ViewResult。

有没有办法以这种方式验证 HandleError 属性的行为？ 还是我的做法完全错误？ 我意识到我可以使用 Selenium（会命中实际服务器的浏览器内测试）来验证实际浏览器中的行为，但是模拟此类测试可以让我更快地完成此操作，并且开销要少得多...

示例测试代码：

// WidgetController.Index() makes a call to GetWidgets to retrieve a 
//  List<Widget> instance.

// this works as expected since the appropriate ViewResult is returned 
//  by the controller
public void TestWidgetControllerIndex_NoResultsFound()
{
    var mockBR = new Mock<IBusinessRules> { CallBase = true };
    mockBR.Setup(br=>fr.GetWidgets()).Returns(new List<Widget>());    
    WidgetController controller = new WidgetController(mockBR.Object);
    ViewResult result = (ViewResult)controller.Index();
    Assert.AreEqual("Index", result.ViewName);
    Assert.AreEqual(0, 
        ((WidgetIndexViewData)result.ViewData.Model).Widgets.Count);
}

// this test is unable to reach the assertion statements due to the problem 
//  outlined above. WidgetController.Index has the HandleError attribute 
//  properly applied and the behaviour via the interface is as expected
public void TestWidgetControllerIndex_BusinessRulesExceptionEncountered()
{
    var mockBR = new Mock<IBusinessRules> { CallBase = true };
    mockBR.Setup(br=>fr.GetWidgets()).Throws<ApplicationException>();    
    WidgetController controller = new WidgetController(mockBR.Object);
    ViewResult result = (ViewResult)controller.Index();
    // The ApplicationException thrown by the business rules object bubbles 
    //  up to the test through the line above. I was expecting this to be 
    //  caught and handled by the HandleError filter (which would then let  
    //  me verify the behaviour results via the assertion below)..
    Assert.AreEqual("Error", result.ViewName);
}

对于我可能做错了什么或者我是否只是从完全错误的方向接近这个问题的任何建议，我将不胜感激。 我假设在控制器方法级别进行测试是合适的方法，因为这是应用 HandleError 属性的地方。（如果我确实需要在应用程序级别进行测试，是否可以通过类似的方法来做到这一点实例化对象而不是使用像 Selenium 这样的东西？）

更新 我得出的结论是，我不应该在每个控制器操作上测试与 HandleError 属性相关的功能。 我实际上并不关心它的作用，我只是想确保错误得到处理（从我的测试角度来看，无论它的自定义代码还是 MVC 库都没有什么区别，这是我想要验证的功能）。

我最终所做的是将控制器操作包装在 try/catch 块中，以便强制返回 Error 视图作为方法的结果（而不是 ErrorHandler 属性在错误离开方法时捕获错误）。 这样我就可以在单元测试中断言错误已通过适当的反馈得到正确处理。 我对这添加到我的控制器方法中的额外长度不太满意，但它确实让我可以向用户提供友好的、特定的错误消息（我正在使用扩展方法来显示反馈并执行日志记录）。 （所以 try/catch 方法肯定有优点和缺点..）

我不是 100% 肯定这是最干净的方法，但它实现了我的目标，即能够验证错误是否通过控制器处理单元测试（快）而不是必须在浏览器中执行测试（慢）。 所以基本上现在足够好，直到我找到一个更干净的解决方案。 如果有人遇到类似问题并找到更好的解决方案，我决定提供赏金。

Answer 1

我认为你不能对此进行单元测试。 你也不想。 您可以测试控制器方法是否引发预期的异常。 使用反射，您可以测试操作或控制器是否具有您期望它具有的属性，以及该属性是否具有某些预期的属性值。 但是，拦截异常并执行属性的工作是框架的行为，而不是您的代码。 一般来说，您不应该测试不属于您的代码（框架）。

Answer 2

是的，我同意蒂姆的观点。 您所描述的是集成测试。 HandleErrorAttribute 的行为取决于底层 ASP.NET 行为，例如您在 web.config 中是否打开或关闭了自定义错误。

对于您的单元测试，您可以简单地使用反射来验证该属性是否存在。
MVC 团队对 HandleErrorAttribute 有单元测试，因此您不需要编写这些单元测试。 :) 然后只需手动测试您的操作以确保这是您想要的行为。 只要您从不更改/删除该属性，行为就不应该改变。

如果您想自动化集成测试，您可以使用 Watin 或 Selenium 来自动执行实际的浏览器请求，以确保您的应用程序行为不会改变。