首页 测试 体会 查看内容

编写可测试的 JavaScript 代码

2014-6-25 14:32| 发布者: tianzc| 查看: 817| 评论: 0

摘要:   Twitter 的工程师文化要求进行测试,许多的测试。在进入 Twitter 之前我还未有过测试 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 模块模式》 在程序中创建强大的单例。这种做法简单有效,但是给测试带来了问题。理由很简单:  单例在测试间造成了状态污染 。与其把单例当作模块使用,不如把他们写成可构造的对象。一旦应用程序初始化,就在全局层上分配一个单一的、默认的实例。  例如,考虑如下的单例模块(当然,是人为的例子):
123下一页

鲜花

握手

雷人

路过

鸡蛋

扫一扫关注最新动态

毒镜头:老镜头、摄影器材资料库、老镜头样片、摄影
爱评测 aipingce.com  
返回顶部