B.6　最佳实践

本附录中展示的示例都非常简单，这一点相信读者是可以理解的。但在实际测试当中，有可能要编写测试代码来验证一些非常复杂的行为是否正确。

理想情况下，应该尽量保持测试代码简单，即便是要测试的行为比较复杂，也要尽力把代码写得简单明了。通过针对少量特定的情况编写测试，可以在不考虑所有输入的情况下，得到对要测试行为的相对合理的确定性结果。

不过，即使针对某个行为编写了测试，代码中也有可能会出现错误。在测试通过但仍然出现错误的情况下，正确的反应不是立即修复问题，而是首先针对失败的行为编写一个新测试。这样一来，不仅可以验证在修复代码之后是否解决了问题，而且也添加了一个可以在将来避免回归的测试。

除了进行单元测试之外，QUnit还可以用于功能测试。单元测试主要是为了验证代码单元（方法和函数）的操作是否正确，而功能测试则是为了确保用户输入能够在界面上得到响应。比如说，第12章实现了一个表格排序功能。我们可以针对排序方法编写一个单元测试，验证调用该方法后表格确实进行了排序。另外，还可以编写一个功能测试，模拟用户单击表格的表头，然后观察结果以确定表格确实被排序过了。

　可以将 dominator.js （ http://mwbrooks.github.io/dominator.js/ ）和 FuncUnit（http://funcunit.com/）等功能测试框架与QUnit一起使用，从而简化编写功能测试和模拟事件的工作。如果想在不同浏览器中实现自动化测试，可以再选择 Selenium（http://seleniumhq.org）等专用的功能测试框架。

为了确保测试中得到一致的结果，需要使用可靠的且未经修改的采样数据。在测试应用到动态站点的jQuery代码时，如果能捕获并存储相应页面的一个静态版本，然后基于该版本来运行测试就比较好。这样也可以隔离代码的组件，从而更容易判断出错误是由服务器端代码还是由客户端代码导致的。

延伸阅读

这些注意事项并没有包含所有情况。测试驱动开发这个主题本身很庞大，短短的一个附录不可能涵盖它的全部内容。以下给出一些有关这方面的在线资源，读者朋友可以自行参考学习。

这方面的图书也有很多，比如Kent Beck的Test Driven Development: By Example和Christian Johansen的Test-Driven JavaScript Development。