编写可测试的JavaScript代码

编写可测试的JavaScript代码

既然要对代码进行测试，那么为什么不让这一过程变得尽可能简单和轻松呢？JavaScript客户端代码测试之所以尤其困难，是因为我们几乎无法控制代码运行的环境。多种类型的操作系统、多个版本的操作系统、多种类型的浏览器、多个版本的浏览器，更不用说插件、扩展、多语言版本和缩放大小了，还有一些未知内容，所有这些因素交织在一起，阻碍着应用程序的性能。这些因素会导致程序变慢、中断、崩溃，最终覆灭。

这里面的内容纷繁复杂！服务端JavaScript给了我们更多的控制权，以便我们能够从总体上控制执行环境。然而，Rhino和Node.js应用程序不像其他语言一样有完整的成熟工具、测试程序以及生态系统。

此外，Node.js的异步特性也使得测试变得更加复杂。有趣的是，这样一种与异步执行密切相关的语言，竟然没有设置与该执行模式相配的内置支持。

无论如何，测试——尤其是JavaScript测试——是很复杂的。克服这种复杂性的最好办法是完全控制自己实际所控制的东西：代码。代码是连续存在的，一方面是从别人的代码到自己的代码，另一方面是从遗留代码到非遗留代码。

什么是遗留代码（legacy code）？

我比较推崇Michael Feathers在他的优秀作品Working Effectively with Legacy Code（Prentice Hall出版社）中的定义：遗留代码是没有测试过的代码，这段代码将无法存活或永远不会被任何人接触到。再次接触遗留代码时，就是要重写它了。看一下当前的项目，任何没有被测试的代码都有可能会被重写。

重写的人可能不是原作者，而是负责处理这个任务（增强代码或修补漏洞）的人。除非这些代码经过测试，否则它们就是必须要重写的无用代码。这段代码可能很惊人，但它唯一能存活的方法就是永远不会产生Bug，并且没有人要求对它进行增强或者添加新特性。

即便如此，你愿意将这些未经测试的产品代码推到市场上吗？

即使代码之前“能用”，之后你还能继续满意吗？拥有该代码的公司也是同样满意吗？因此，通常的结果都是付费重写。公司不得不再次付费进行代码重写，这真是太糟糕了，但这就是遗留代码的情况。