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