关于视图的单元测试
说到ASP.NET MVC，我们似乎始终都在关注对于Controller的测试——虽然Stephen Walther也写过如 何脱离Web Server对View进行单元测试，但是他的方法可看而不可用。复杂的构造和预备，以及对生成的 HTML字符串作判断——这真是在对视图做单元测试吗？仔细分析他的代码可以发现，这其实是在对 ViewEngine做单元测试。而且，如果真要对ViewEngine做单元测试，也不应该像他那样依赖外部文件。在 我看来，他的做法什么都不是……似乎美观，似乎能博得一些“掌声”，但是这个掌声是来自于他的解决 方案，还是大家一时的冲动呢？
如果要对视图做单元测试，还是要将内容呈现在浏览器中才行。在对网页做单元测试时，我们一般会 使用WatiN等工具操作浏览器，打开页面，再对其DOM元素结构及内容作断言。不过……这是单元测试吗？ 可惜这只能算是一种回归测试或用户验收测试。因为，我们在打开一个页面的时候，从表现层到业务逻辑 再到数据访问，应用程序的每个部件都在忙碌着。而单元测试讲究的是“分离”，分离一切关注，分离一 切依赖。因为分离，我们才能准确定位错误；因为分离，我们才能在测试中使用我们准备好的数据。
既然要分离，我们就必须遵循一定的使用规范。在《ASP.NET MVC单元测试最佳实践》中我提到，在 View中只能使用ViewData中的数据，而不该依赖其他内容（包括HttpContext）。这样我们就可以自行构 造ViewData并注入一个视图对象中。事实上，这个约定在ASP.NET MVC自带的项目模板中就被破坏了。请 看Views\Shared\LogOnUserControl.ascx，其中通过this.User来查看当前用户的登陆状态。这是个定义 在传统Page对象上的属性，从当前HttpContext上直接获取。如果使用这种方式，我们在单元测试时就难 以“模拟”当前用户的登陆状态，进而难以使测试覆盖到测试的各种情况了。
Lightweight Test Automation Framework
在这里，老赵推荐使用ASP.NET Team提供的Lightweight Test Automation Framework（下文称之为 LTAF）作为测试工具，它目前已经在CodePlex上更新至Feb Update版本。这个框架的作用与WaitN和 Selenium类似，可操作浏览器对应用程序编写回归测试。虽然在某些方面（例如DOM元素的选取）不如“ 竞争对手”，但是LTAF自有其独到之处：
由于直接在浏览器中运行，它天生便支持现有的——以及未来可能出现的任意浏览器。
由于直接部署在被测试的网站中，因此测试代码和网站页面是在同一个进程中。
第一点优势自不必说，而第二点更是关键。试想WaitN和Selenium，都是通过编写代码在浏览器中打开 页面。这意味着我们的在测试代码和被测试的网页分别在不同的进程中。在这个前提下，如果我们要将测 试代码中定义的数据传递给被测试的网页（也就是视图对象），我们就必须进行跨进程的通信。而无论怎 么实现，都逃不过“序列化”一途，这无疑增加了复杂度。而使用LTAF之后，这个问题瞬间烟消云散了， 因为我们可以直接在内存中“传递”测试数据，一切都只是个引用而已。
不过任何事物都具有两面性，LTAF也有一些难以天生的，而且是永远无法弥补的缺点。例如：
由于LTAF将待测试的页面放置在Frame中，因此该页面上的window.top等基于浏览器frame结构的属性 会被改变。
由于LTAF的本质是使用JavaScript来操作DOM，这意味着任何会阻塞程序进行的操作（例如alert）都 不能使用，否则将阻塞整个测试过程。
不过幸运的是，这两点都不回成为严重的问题。对于第一种，我们只需要编写一个自定的getTop方法 来替换直接访问windows.top的做法即可。而第二种情况——老赵从来不喜欢alert或confirm这种“纯浏 览器功能”，因为它们会带来很差的用户体验，更何况现在的JavaScript类库/框架都能很轻松的做出这 种效果，您觉得呢？
LTAF的具体使用方式可参考其Release Note。令人奇怪的是，老赵发现直接在项目中使用LTAF会有一 些小问题（不过它的示例为什么就一切正常呢？），因此进行了一些细微的修改。请注意 ~\UnitView\DriverPage.aspx文件尾部的一些JavaScript代码。