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

　　提供文档。你是不是经常遇到看不懂的代码？这些代码可能没有任何文档说明，而且开发代码的人可能早就走了（或者度假去了）。当然，看到这种代码的时间往往也很不合时宜，可能是凌晨3点，也可能有位副总在你旁边大声催促着赶快解决昨天的问题，这样要想花些时间来明白原作者的意图就更困难了。我们见过一些好的单元测试文档，它们会指出系统要做什么。测试就像原开发人员留下的记号，可以展示他们的类具体是怎么工作的。

　　改善设计：编写测试能改善设计。测试有助于你从界面的角度思考，测试框架也是代码的客户。测试能让你考虑得更简单。如果你确实遵循了“尽量简单而且行之有效”的原则，就不会写出篇幅达几页的复杂算法。要测试的代码通常依赖性更低，而且相互之间没有紧密的联系，因为这样测试起来更容易。当然，还有一个额外的作用，修改起来也会更容易！

　　鼓励重构：利用一套健壮的测试集，你能根据需要进行重构。你是不是经常遇到一些不知是否该修改的代码？种种顾虑让你行动迟缓，过于保守，因为你不能保证所做的修改会不会破坏系统。如果有一套好的单元测试集，就能放心地进行重构，同时能保证你的代码依然简洁。

　　提高速度：编写这么多测试会不会使开发速度减慢呢？人们经常会以速度（或开发开销）作为反对进行TDD和使用xUnit框架的理由。所有新的工具都会有学习曲线，但是一旦开发人员适应了他们选择的框架（通常只需很短的时间），开发速度实际上会加快。一个完备的单元测试集提供了一种方法对系统完成回归测试，这说明，增加一个新特性之后，你不必因为怀疑它会不会破坏原系统而寝食难安。

　　提供反馈：单元测试还有一个经常被忽略的优点，即开发的节奏。尽管看上去好像无关紧要，但通过测试之后你会有一种完成任务的成就感！你不会成天地修改代码而没有任何反馈，这种测试—代码—测试的方法会鼓励你动作幅度小一些，通常修改一次代码的时间仅几分钟而已。这样你不会一下子看到冒出一大堆的新特性，而只是让代码基一次前进一小步。