编写可测试的 JavaScript 代码

var dataStore = (function() {var data = [];return {push: function (item) {data.push(item);},pop: function() {return data.pop();},length: function() {return data.length;}};}());　　有了这个模块，我们可能想测试 foo.bar 方法。以下是一个简单的 QUnit 测试套件：module("dataStore");test("pop", function() {dataStore.push("foo");dataStore.push("bar")equal(dataStore.pop(), "bar", "popping returns the most-recently pushed item");});test("length", function() {dataStore.push("foo");equal(dataStore.length(), 1, "adding 1 item makes the length 1");});　　在运行测试套件时，length 断言会测试失败，但是这里很难弄清它为什么会失败。问题就在于上一次测试中 dataStore 的状态留了下来。如果只是给测试重新排序的话 length 测试会通过，但是会有红色标志标明某处出现了问题。我们当然可以使用 setup 或者 teardown 方法，用恢复 dataStore 的状态来修复此问题，但那也同时代表着我们需要在 dataStore 模块的实现改动了以后经常维护这样的测试模板。更好的做法如下：function newDataStore() {var data = [];return {push: function (item) {data.push(item);},pop: function() {return data.pop();},length: function() {return data.length;}};}var dataStore = newDataStore();

Twitter 的工程师文化要求进行测试，许多的测试。在进入 Twitter 之前我还未有过测试 JavaScript 的经验，所以在这之后我学习到了很多。特别是学到了许多过去我使用、书写和鼓励使用的代码其实是不利于书写可测试的代码的。所以我觉得在此分享我所学习到有价值的，如何书写可测试的 JavaScript 几条最重要的原则。这里提供的这些示例虽然基于 QUnit，但是也应该适用于其他的 JavaScript 测试框架。　　避免单例　　我最受欢迎的博文中的其中一篇就是关于如何使用 《JavaScript 模块模式》 在程序中创建强大的单例。这种做法简单有效，但是给测试带来了问题。理由很简单：  单例在测试间造成了状态污染 。与其把单例当作模块使用，不如把他们写成可构造的对象。一旦应用程序初始化，就在全局层上分配一个单一的、默认的实例。　　例如，考虑如下的单例模块（当然，是人为的例子）：