Ajax基础教程（6）- 6.1 JavaScript提出的问题

　　TDD产生于敏捷开发运动，特别是极限编程（extreme programming，XP），而且TDD正是XP的一个核心原则。推崇TDD的人认为，不应该完成开发之后再写测试，这通常只是“马后炮”，而应当在写代码之前先写测试。测试本质上相当于设计文档，而不是花大量时间去摆弄一个复杂的图形化工具，你要直接在代码中“拟画”一个类。开始时先为一些小功能块编写测试。在有些语言下，你写的测试甚至不能编译，因为所引用的类尚不存在。一旦建立了测试，就可以运行这个测试（当然，此时运行测试会失败）。然后再编写最少量的代码，以便测试通过。接下来再重构代码，并增加更多的测试。

　　通常可以使用测试框架来帮助编写自动化测试。最著名的框架是JUnit，不过现在已经有很多xUnit项目，可以简化在各种语言下测试的创建。一般地，这些框架都建立在断言（assert）基础上。开发人员编写测试方法，将调用方法的实际结果与期望结果进行比较。当然，可以人工地检查一个日志文件或用户界面来完成这些比较，但是，用计算机完成数据比较不仅速度快，也更准确。另外，就算是让计算机把同样的测试运行上1500次，它们也不会嫌烦，如果是人可做不到这一点。

　　有了JUnit和其他测试框架，编写和运行测试变得相当简单。这就能鼓励开发人员创建大量测试（往往能更完备地覆盖各种测试情况），而且会乐于经常运行这些测试（可以更快地帮助开发人员找到bug）。在许多情况下，如果项目中采用了TDD，测试代码往往与生产代码一样多！

　　使用TDD可以带来许多重要的好处：

　　提供明确的目标：你很清楚，一旦结束（也就是一旦测试通过），你的工作就完成了（假设你的测试写得很好）。测试会为代码建立一个自然的边界，使你把重点集中在当前任务上。一旦测试通过，就有确切的证据证明你的代码能工作。相对于人工地测试用户界面或者比较日志文件中的结果，在一个xUnit框架中运行自动化测试，速度要快几个数量级。大多数xUnit测试的运行只需几微秒，而且大多数采用TDD的人都会一天运行数次测试。在许多开发小组中，将代码签入源代码树之前，代码必须成功地通过测试。