Twitter 的工程师文化要求进行测试，许多的测试。在进入 Twitter 之前我还未有过测试 JavaScript 的经验，所以在这之后我学习到了很多。特别是学到了许多过去我使用、书写和鼓励使用的代码其实是不利于书写可测试的代码的。所以我觉得在此分享我所学习到有价值的，如何书写可测试的 JavaScript 几条最重要的原则。这里提供的这些示例虽然基于 QUnit，但是也应该适用于其他的 JavaScript 测试框架。
避免单例
我最受欢迎的博文中的其中一篇就是关于如何使用 《JavaScript 模块模式》 在程序中创建强大的单例。这种做法简单有效，但是给测试带来了问题。理由很简单： 单例在测试间造成了状态污染 。与其把单例当作模块使用，不如把他们写成可构造的对象。一旦应用程序初始化，就在全局层上分配一个单一的、默认的实例。
例如，考虑如下的单例模块（当然，是人为的例子）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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 测试套件：
|
1 2 3 4 5 6 7 8 9 10 11 |
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 模块的实现改动了以后经常维护这样的测试模板。更好的做法如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
function newDataStore() { var data = []; return { push: function (item) { data.push(item); }, pop: function() { return data.pop(); }, length: function() { return data.length; } }; } var dataStore = newDataStore(); |
现在，测试套件看起来如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
module("dataStore"); test("pop", function() { var dataStore = newDataStore(); dataStore.push("foo"); dataStore.push("bar") equal(dataStore.pop(), "bar", "popping returns the most-recently pushed item"); }); test("length", function() { var dataStore = newDataStore(); dataStore.push("foo"); equal(dataStore.length(), 1, "adding Ɓ求进行测试，许多的测试。在进入 Twitter 之前我还未有过测试 JavaScript 的经验，所以在这之后我学习到了很多。特别是学到了许多过去我使用、书写和鼓励使用的代码其实是不利于书写可测试的代码的。所以我觉得在此分享我所学习到有价值的，如何书写可测试的 JavaScript 几条最重要的原则。这里提供的这些示例虽然基于 QUnit，但是也应该适用于其他的 JavaScript 测试框架。
避免单例我最受欢迎的博文中的其中一篇就是关于如何使用 《JavaScript 模块模式》 在程序中创建强大的单例。这种做法简单有效，但是给测试带来了问题。理由很简单： 单例在测试间造成了状态污染 。与其把单例当作模块使用，不如把他们写成可构造的对象。一旦应用程序初始化，就在全局层上分配一个单一的、默认的实例。 例如，考虑如下的单例模块（当然，是人为的例子）：
有了这个模块，我们可能想测试 foo.bar 方法。以下是一个简单的 QUnit 测试套件：
在运行测试套件时，length 断言会测试失败，但是这里很难弄清它为什么会失败。问题就在于上一次测试中 dataStore 的状态留了下来。如果只是给测试重新排序的话 length 测试会通过，但是会有红色标志标明某处出现了问题。我们当然可以使用 setup 或者 teardown 方法，用恢复 dataStore 的状态来修复此问题，但那也同时代表着我们需要在 dataStore 模块的实现改动了以后经常维护这样的测试模板。更好的做法如下：
现在，测试套件看起来如下：
|
