谈到应用程序的UI其实包括两个方面的内容一方面是纯图形的look feel另一方面则是用户和应用程序的交互。用户和应用程序的交互往往同时导致图形界面的变化并且转换到新的交互行为。由于工作实践中主要是基于WEB的HTML和JavaScript的项目这里对TDD in UI的讨论将focus在基于HTML和JavaScript的UI。同时一般来讲WEB程序的表现层主要有客户端代码和服务端代码而服务端代码相对来说更容易被测试。所以本文讨论的重点主要focus在客户端代码。换句话说这里讨论的TDD in HTML JavaScript指的是对于客户端的HTML和JavaScript的TDD。TDD in HTML JavaScript 之可行性说到可行性其实可以分两个层面理论上的可行性和实际应用的可行性。第一个问题是纯图形的look feel理论上可以进行自动化的测试吗答案几乎是否定的。因此主要用于呈现纯图形的HTML及CSS也几乎是很难自动化测试的。那么用户和应用程序的交互理论上是否可以进行自动化测试呢答案毫无疑问是肯定的。WEB交互的测试其实可以根据WEB程序的架构分为两种类型传统的WEB程序主要基于服务端来呈现内容用户和页面的交互主要是getpost数据和页面跳转。因此对应的测试方式主要也是由测试工具模拟需要get或post的数据并且跟踪期望的页面跳转情况。这种情况下的测试其实相对简单因此本文不想过多讨论。当前的基于AJAX的WEB程序则很大程度上丰富了用户和页面交互的方式用户和页面的交互除了传统的getpost数据和页面跳转在页面不刷新的情况下还通过触发各种DOM事件甚至直接触发JavaScript方法的执行由JavaScript来改变和呈现内容。此时传统的只能模拟需要get或post的数据的测试工具就无能为力了。此时由于所有的逻辑代码都在JavaScript中所以本质上其实是需要对大量的JavaScript代码进行测试。此正是本文希望讨论的重点。首先针对JavaScript的自动化测试工具其实已经有不少了如JsUnitTestQUnitMock工具也有jqMockJSMock支持直接重构JavaScript代码的工具相对比较少提供的功能也都还非常弱IntelliJ IDEAEclipse从支持工具的现状可以说影响TDD in JavaScript的实际可行性的因素之一是重构工具的缺乏。不过最近的情况有了一些改变现在也出现了一些支持JavaScript重构的变通的解决方案如Script# - Write C# codecompile C# source code directly to JavaScript codejsc – Write any .NET code, convert .NET assembly to JavaScript, ActionScript, java or PHP code这些方案的特点是利用现有的IDE对流行的编程语言如C#源代码的完善的coding尤其是强类型重构和测试的支持让开发人员写C#由工具转换为可直接执行的格式化的JavaScript代码。除了充分利用IDE对流行语言的coding支持之外这类方案的另一个好处是相对于高薪聘请Senior的JavaScript开发人员Junior的C#的开发人员要便宜得多也易招得多但得益于Script#已经足够能用他们熟悉的C#写出逻辑复杂和OO的JavaScript代码因此开发成本被大大降低。综上所述TDD in JavaScript不仅理论上是可行实际应用上也是有足够的工具支持的。尤其是如Script#这样的工具的出现极大地提高了JavaScript代码的开发效率。TDD in JavaScript 之最佳实践谁都希望能有最佳实践。什么是最佳实践呢有很多人见不得“best”“最”这样的词认为这个世界上没有“最”的东西。有吗当然有我们首先要略为上升到哲学的高度对于包含“最”这样的词汇的命题如果想要为“真命题”则必然是需要加上一个适当的前提条件的。比如说我说“我是这世界上最NB的人”。这毫无疑问是个假命题。因为缺乏适当的前提条件。你可以自己做个练习如果觉得这个命题假想办法给它加上更多的前提条件一定能让它变真。所以所谓最佳实践指的是对一个或者一类特定的问题在一个相对确定的背景下所能采取的实际处理的方案典范。加上前提条件则“最佳实践”当然是存在的也是值得讨论的。通过前面的章节我们已经把本文重点讨论的主题限制到一个相对小的范围那就是对基于AJAX的WEB应用程序中的大量的JavaScript代码如何进行TDD并且我们也收集了足够的支持TDD需要的各种工具包括自动化测试工具Mock工具和重构工具。在这些工具的支持下很大程度上WEB程序客户端JavaScript代码的TDD和服务端代码的TDD不应该有很大的区别。但同时由于客户端代码的特殊性自然也应该有一些客户端脚本代码所特有的实践模式。以下首先列出本人推荐的一些实践模式希望大家能一起修正和补缺。最佳实践一应用MVC模式在传统的非AJAX的WEB程序中JavaScript往往处于非常辅助性的地位。除了实现一些特效和数据验证等辅助功能之外一个页面的JavaScript代码恐怕屈指可数自然无所谓测试甚至是TDD了。但是在现在的复杂的AJAX应用中以往必须由多个独立页面的getpost和页面跳转才能组合实现的功能通过JavaScript可以在一个无需刷新浏览器的页面中轻易实现不但用户体验更佳速度更快对服务器的负担也更小。此时原本传统WEB程序的服务端需要处理的问题如数据绑定事件绑定逻辑控制等需要在客户端进行处理。也因此原本为了解决WEB程序服务端代码可测试性问题MVC模式也就一样可以良好的应用于客户端。清晰的将JavaScript代码分割成MVC将能够把相同的逻辑职责尽可能集中到一起来管理从而极大地增加客户端代码的可维护性和可测试性。下表简单对比服务端和客户端MVC下MVC的对应职责ModelViewControllerServer Side返回用于呈现页面内容的数据的 Domain Objects代表了一个页面的抽象包括页面的内容呈现数据事件定义处理View上触发的事件获取数据更新View上的数据触发View的内容呈现Client Side返回 JSON 数据的 Restful Services同上同上最佳实践二应用依赖注入和IoC容器应用MVC模式本质上是抽象的逻辑职责上的解耦。而依赖注入和IoC容器则是代码的物理依赖性上的解耦。尽可能的利用构造器注入设值注入接口注入或IoC容器来解除具体的实现类之间的直接依赖自然就能极大的大提高每个具体的实现类的可测试性。最佳实践三应用模板引擎呈现主体内容AJAX应用中的一个需要客户端呈现的View必然需要呈现一些HTML这些HTML往往需要根据Model返回的JSON数据动态构造。一般来讲我们会有三种方式来构造和呈现这些HTML在JavaScript中遍历JSON数据拼接HTML字符串呈现到页面上在JavaScript中遍历JSON数据动态实例化DOM对象通过DOM对象的方法呈现HTML的DOM通过如JTemplate这样的JavaScript模板引擎将JSON数据绑定到一个HTML模板由模板引擎呈现最终的HTML