昨天就想发起这个话题的讨论，只是觉得对于讨论的支持，自由互联现有的功能天然似乎还不能很好的支持。所以有了突然发现想在自由互联发起一个有价值的讨论其实很难一文。亚历山大同志提到“自由互联的讨论需要发起争议性话题，比如 .net sucks之类”。回顾如关于近期C#大论战的回应这样的近期引起讨论的焦点话题，貌似确实如此。深以为叹。近期的C#大论战是幸运的，尽管中间还是参杂了很多口水，李建忠老师的加入，一定程度上最终将话题引向了正确的方向。幸哉。我这个围观群众也从中获益良多。不仅仅是对于这个技术话题正确理解，还包括李老师在他的博客最后提到的：抛掉“非要辩个胜负，分个高低”的怪诞氛围，而是来一些扎扎实实的技术说理过程，相信会更有意义——如是，则国内技术社区成长可待。
言归正传，还是尽快开始我想讨论的主题，且不管讨论最终成效如何，既然发起讨论，还是先尽可能分享自己的想法，以示诚意。
TDD的背景自从03年Beck正式提出（事实上在00年，Beck提出eXtreme Programming时，就已经提出了这个词）Test-driven design/development这样一个基于测试优先、重构和迭代的革命性的开发方法以来，无数的实践已经证明，对于适合进行TDD的领域，TDD能够极大地提高代码的可维护性和开发效率。
TDD的基本流程图如下：
在这样一个迭代的流程中，在写任何的production code之前，先写test，再写production code，并且不断地对代码进行清理和重构，并且每次迭代都要进行回归测试，保证新增的test和production code不会break任何已有的test和production代码。
一般来讲，支持自动化的回归测试的工具相对比较容易实现。整个流程中的难点在于：当先行写test代码的时候，必然要求先定义被测试的production code的外部接口，对于第一次迭代，自然没有问题；但是，由于需求的变更，或者整体设计的变更，在后续的迭代过程中，经常会发生，已有的已经实现并且包含完整测试的production code的外部接口需要变更或者说重构；尽管从理论上，绝大多数的重构需求，都有规律甚至是模式可循，但是，如果完全依赖于人工操作，则不仅效率不高，且极易出错。所以，但凡成功的TDD实践，其中都不乏很多支持重构的工具。比如，现行绝大多数的集成开发环境，都有很多自动化的代码重构工具，大大的降低了代码重构的成本。
但是还有一些领域，TDD还略微有些力不从心，或者说，至少，至今没有看到太多比较好的实践案例。比如：对于Database和UI。
对于数据库开发的TDD，到目前为止面临的主要挑战是工具的支持。无论是自动化的回归测试工具，还是重构工具都还远远不够成熟。
而对于UI的TDD，则是本文的主题。
TDD in HTML & JavaScript 概述谈到应用程序的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程序主要基于服务端来呈现内容，用户和页面的交互，主要是get，post数据和页面跳转。因此，对应的测试方式，主要也是由测试工具模拟需要get或post的数据，并且跟踪期望的页面跳转情况。这种情况下的测试其实相对简单，因此本文不想过多讨论。
- 当前的基于AJAX的WEB程序则很大程度上丰富了用户和页面交互的方式，用户和页面的交互，除了传统的get，post数据和页面跳转，在页面不刷新的情况下，还通过触发各种DOM事件，甚至直接触发JavaScript方法的执行，由JavaScript来改变和呈现内容。此时，传统的只能模拟需要get或post的数据的测试工具就无能为力了。此时由于所有的逻辑代码都在JavaScript中，所以，本质上其实是需要对大量的JavaScript代码进行测试。此正是本文希望讨论的重点。
首先，针对JavaScript的自动化测试工具其实已经有不少了，如：
- JsUnitTest
- QUnit
Mock工具也有：
- jqMock
- JSMock
支持直接重构JavaScript代码的工具相对比较少，提供的功能也都还非常弱：
- IntelliJ IDEA
- Eclipse
从支持工具的现状，可以说，影响TDD in JavaScript的实际可行性的因素之一是重构工具的缺乏。
不过，最近的情况有了一些改变，现在也出现了一些支持JavaScript重构的变通的解决方案，如：
- Script# - Write C# code，compile C# source code directly to JavaScript code
- jsc – 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应用中，以往必须由多个独立页面的get，post和页面跳转才能组合实现的功能，通过JavaScript，可以在一个无需刷新浏览器的页面中，轻易实现，不但用户体验更佳，速度更快，对服务器的负担也更小。
此时，原本传统WEB程序的服务端需要处理的问题，如数据绑定，事件绑定，逻辑控制等，需要在客户端进行处理。也因此，原本为了解决WEB程序服务端代码可测试性问题MVC模式，也就一样可以良好的应用于客户端。清晰的将JavaScript代码分割成M，V，C，将能够把相同的逻辑职责尽可能集中到一起来管理，从而极大地增加客户端代码的可维护性和可测试性。
下表简单对比服务端和客户端MVC下M，V，C的对应职责：
Model
View
Controller
Server 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；
本最佳实践的建议内容就是，对于一个View的主体内容，应该尽可能的通过模板引擎来呈现。为什么呢？因为，对于一个WEB程序来说，最不稳定的，会经常变化的部分，无疑是纯图形的HTML和CSS，使用模板引擎，将能够使得这些HTML尽可能的集中，并且易于修改，也更易于HTML和JavaScript的整合。
最佳实践四：应用Script#应用Script#好处前面已经提过了，这里再简单列举一下：
- 充分利用现有的IDE对流行的编程语言如C#源代码的完善的coding，尤其是强类型，重构和测试的支持；
- 相对于高薪聘请Senior的JavaScript开发人员，Junior的 C#的开发人员要便宜得多；
如反对，请列举我不该用它的理由？
对于以上几个最佳实践的应用实例，请参见我之前的文章：This is jqMVC# – CNBLOGS Google Tracer Sample。
欢迎补缺、指正！谢谢！
【本文来源：韩国服务器 http://www.558idc.com/kt.html欢迎留下您的宝贵建议】