我在我的申请中提出了一个小问题。
我将主应用程序的命名空间从MyApp.Models更改为MyApp.ViewModels，以便命名空间总体上不那么混乱（因为该命名空间只有视图模型而没有业务模型）。我更改了所有可以找到的引用，包括在我的视图中，我重新运行了所有的单元测试并完成了应用程序，一切都很好。
几天后，我收到一份报告，说明注册页面出现时出错了。看完之后，我忘记在注册页面上修复命名空间，因此无法编译视图。
这让我担心。单元测试的全部要点，以及Asp.Net MVC最大的诱惑之一，就是能够通过自动单独测试所有内容来确保您的应用程序，以便您在修改时立即知道系统的某些部分。现在看来，这似乎是一个重要的漏洞。
要清楚，我知道您可以打开预编译视图。但是，我不喜欢这个选项，因为它一直都不是一个好主意（因为它使得编译新的构建非常非常慢），并且有一个单独的配置方案，这意味着它取决于用户记得尝试使用该配置方案进行编译以检查视图编译错误。
这也完全绕过检查可能发生的运行时错误。例如，假设您更改了强类型视图所期望的视图模型。然后，您将更新单元测试以确保Controller.Action()正在返回具有正确视图模型类型的视图结果，但这不会确保实际视图已针对新视图正确更新，此方案将导致运行时异常。这是一个容易发生的情况，特别是因为如果两个视图模型中的差异仅在视图中使用的部分中看到。
可能导致视图中的运行时异常的代码的其他示例是不正确的循环（可能由视图模型中的更改引起），检查用户角色的代码（因此仅为具有凭据的用户显示按钮），不正确的强制转换（例如用于将集合转换为选择列表），用于对集合进行排序的错误代码（如何在显示中对集合进行排序可视为视图问题，而不是控制器或视图模型问题），如果用于文件位置的字符串不在正常工作（T4MVC与某些东西没有很好的集成，比如Telerik的脚本注册系统）等......
我看到它的方式，有许多事情可能导致在渲染视图的过程中发生异常，我似乎无法找到任何方法来创建单元或集成测试以确定何时发生。如果我不必检查每一页以确保我错过了标准单元测试应该能够捕获的内容的编译时间或运行时错误，我会感觉更舒服。
我有什么选择呢？
我宁愿远离WaTiN和其他GUI测试工具，因为我对页面的实际显示不感兴趣，我只想知道视图是否呈现或是否发生异常而不需要Watin为每次测试运行IE实例的开销（我也认为如果我稍后继续进行集成，这将导致问题。）
答案 0 :(得分：3)
如果您不想使用WaTIN和IE，那么如何在IIS Express中启动您的网站，然后在每个视图的网址上使用HttpWebRequest来检查结果是200 OK。这是一个完整的集成测试。
否则，您必须从控制器获取ViewResult，并调用传递包含存根ExecuteResult的{{1}}的{{1}}方法。这样可以提供更多真正的单元测试，速度会更快，但是在它工作之前你需要做很多嘲弄和捣乱。
答案 1 :(得分：1)