不晓得有多少人在做前端技术开发，问过在我之后加入公司的，或者面试过的前端工程师，几乎都没有在写前端技术。他们有的来自于百度，新浪，SAP等。当然，我在这不能以偏概全，写了Testing的不情愿来也说不一定。半年前，我还没受TW的影响，无聊中在看过jQuery的Testing之后有了一些Testing方面的思考，开始尝试地去为我的各种库加单元Testing。那时候接触到的唯一一个Testing框架就是QUnit。

QUnit不但是我接触到的第一个前端框架，也是那时候了解的最全面的单元Testing框架，超越了对JUnit和NUnit（后两个只是蜻蜓点水般玩了下）。在完成功能之后加上Testing，然后看Testing通过，然后开心地又加几个功能，再写几个Testing，那种感觉说不出的爽。

我把前端技术分成两个大类，一类是使用js开发的模块，偏向逻辑的单元Testing，比如前端MVC中的Controller的Testing，JS类库（underscore、jQuery、Wind.js）的Testing。另一类是UI组件的Testing，因为UI一般包含了标记、事件处理、动画、样式等元素，Testing将会变成功能Testing，甚至是集成Testing。而且因为含有标记，样式和复杂的事件处理，不能使用自动化Testing百分百模拟人工操作，所以做这一类的Testing比较难一些。据我所知，现在的前端开发Testing框架数QUnit、Jasmine、Mocha、JsTestDriver这四个比较出名，用来写Testing都是很上手的。

QUnit

QUnit是XUnit系列在前端技术领域中的后继者，提供了单一的testcase的写法和assert断言方式，结构十分简单。详细的介绍可以在官网介绍页面找到，其所有的assert断言方式也可以断言列表中查看。

QUnit编写的单元Testing可以在浏览器和Nodejs进行Testing，由于QUnit提供了非常华丽的浏览器报表样式，个人还是推荐QUnit用例放在浏览器中跑。

QUnit自身没有提供任何Spy，Stub和mock的技术，所以在集成Testing方面比其他框架要弱，可以使用第三方的Testing类库帮助，比如Sinon.js，是一个独立的Testing帮助类库，以后写文章详细介绍。

Jasmine

Jasmine号称自己是行为驱动Testing（BDD）框架，语法和RSpec几乎一样，用describe描述Suites，用it描述一个Testing用例。在单元Testing中，一般一个Suite用来描述一个类，或者一个含有多个Testing用例的方法。Jasmine中提供了有语义的断言方式，使用expect和not的链式调用。看看下面这个case就能了解到Testing写起来也可以很优雅。

it("and can have a negative case", function() {
  expect(false).not.toBe(true);
});

Jasmine和QUnit一样，可以在Nodejs环境和浏览器中执行，在Nodejs环境中有很多NPM包可以使用，比如jasmine-node。在公司接触到的Rails项目，基本上都是集成jasmine来做前端技术，传统运行界面比较丑，可以试试有所改善standalone版本。如果想在jasmine中TestingUI操作，可以使用jasmine-jquery，它提供了载入fixture的功能，并且自定义了很多断言中使用到的matchers，比如断言一个元素是否有某个样式可以这么写：

expect($('#target')).toHaveCss({margin: "10px"});

Jasmine提供了spy方法，可以通过它创建fake方法调用，从而断言方法是否被调用，被调用多少次，或者验证接受的参数是否正确等等。另外，使用spy对象的andCallFake方法也能发挥一些stub的作用。之前提到的Sinon.js同样可以和Jasmine配合使用。

一切都看上还挺顺利的，不过有两个地方我对jasmine不是很爽，一个就是非常ugly的异步Testing，如果在代码Testing中间遇到了异步调用，就需要用到waitsFor方法，此方法接受一个方法，当方法返回true时运行异步调用之后部分，因为异步调用不会阻塞代码运行，所以必须使用一个runs方法把之后部分包住，超过两次的异步调用会导致写出来的代码各种让人看不懂，这一点还不如QUnit的stop和start方法易懂好用，在Mocha中的异步Testing也优雅得多。另一个是发生在TestingUI组件时，因为所有Testing都会在同一个文件中运行，而且需要预先把Testing的样式和脚本资源都载入到页面中，先不说样式之间会相互影响导致断言失败的问题，在Testing过程中如果存在动态创建元素到页面的情况可能会导致回收fixture时忽略掉新创建的元素导致错误。我期望的UITesting是为每case提供独立的运行环境，首先解决了样式冲突问题，每个UI组件Testing运行的环境只含有为case准备的样式和脚本，我有想过用父子页面实现，脚本在父窗口中运行，操作子窗口中的UI组件。而且，新元素的回收问题在每次子窗口重载UI组件的时候也得到解决。

这是我觉得ugly的一个Testing

describe("Asynchronous specs", function() {
  var value, flag;
 
  it("should support async execution of test preparation and exepectations", function() {
 
    runs(function() {
      flag = false;
      value = 0;
 
      setTimeout(function() {
        flag = true;
      }, 500);
    });
 
    waitsFor(function() {
      value++;
      return flag;
    }, "The Value should be incremented", 750);
 
    runs(function() {
      expect(value).toBeGreaterThan(0);
    });
 
  });
});

Mocha

摩卡coffee，香飘四溢。当我第一次接触到它的时候，我果断放弃了Jasmine，我说放弃是心里上放弃了，因为Mocha主打Nodejs环境，虽也弱弱地支持浏览器运行，但在浏览器端运行和Jasmine比较没有多大优势，但Mocha在Nodejs上的运行比Jasmine-node好出很多，而且支持多种报表的输出，不仅有优秀的字体着色和报错显示，还有些非常有趣，比如飞机从左飞行到右的进度条提示。特别有用的还有json和html格式的jscoverage报表。我的Mr.Coverage就是使用的html格式的报表。

Mocha的语法和Jasmine几乎一样，有时甚至支持直接跑Jasmine的Testing。它支持三种断言方式，包括QUnit的assert方式、Jasmine的expect方式，另一种是更具语义的方式should.js，最后一种也是我最喜欢的一种，它的实现强烈推荐去看看。使用should可以看到一些DSL的影子。写法十分优雅呢，使我爱不释手。在这里需要提到一个非常优秀的断言类库Chaijs，使用它可以让Testing框架支持assert、expect、should三种断言方式。并没试过在QUnit里面使用Chaijs，从文档上看应该是支持的。

var user = {
    name: 'tj'
  , pets: ['tobi', 'loki', 'jane', 'bandit']
};
 
user.should.have.property('name', 'tj');
user.should.have.property('pets').with.lengthOf(4);

Mocha并没有自己提供什么spy，stub，mockTesting技术，官方也推荐直接使用sinon.js。

在Nodejs中运行Testing时候都需要运行命令，每次修改代码后都需要重新运行命令，Mocha里面提供了watch的功能，当文件修改之后都会自动运行Testing。

如果是在浏览器中运行，那么会遇上一个更大的麻烦之处，就是浏览器兼容性Testing，在每次修改代码之后，为了保证每个浏览器都能运行通过，所以需要每个浏览器都刷新一下。想想都觉得程序员浪费时间在这些地方太不值得了。JsTestDriver可以帮我们解决这个问题。

JsTestDriver

JsTestDriver是Google大神的作品，说它是一个框架，不如说它是一个Testing工具。JsTestDriver使用Java打造，所有的使用都是从JsTestDriver.jar包开始的，使用它需要先启动一个server，需要进行Testing的浏览器先要连接到此server，然后运行testcase，所有浏览器都会响应。每次修改代码之后就不用每个浏览器都刷新了，运行命令行就可以了，如果你使用了watch的话，那所有case都会自动在浏览器中运行了。

JsTestDriver并没有什么优雅的语法，断言方式也普普通通，一切都显得非常实在。同时，JsTestDriver还提供了另外一个jar包可以使用它输入代码的行Testing覆盖率，和现有的项目集成使用是十分方便的。

由于JsTestDriver先启用了Testing服务器，所以可以使用它来做远程Testing，比如可以利用它来做产品或者类产品环境的Testing。

Google的MVC框架AngularJS就是使用JsTestDriver进行Testing的，而且在Testing中载入页面时确实是使用一个iframe载入Testing的UI和资源，让case运行在一个独立的环境，解决了我在Jasmine UI组件Testing中遇到的冲突问题。

对前端UI组件Testing，我一直有个疑问，当我需要断言一个样式是否存在一个样式时，是去断言此元素是否含有一个实现此样式的class呢，还是直接断言元素的此样式是否存在。比如在Testingpopup弹出框时，在弹出状态下是验证display属性还是验证弹出框有没有一个名为show的class。因为我觉得有show这个class不一定能代表弹出框一定处于显示状态，所以偏向于直接断言display属性。有人说我关注点太奇怪，但我其实是在想如何能让Testing更能准确地起到验证的效果这个大问题。我承认世事无绝对，自动化Testing永远不能完全代替人工Testing，尤其颜色、视觉的部分更需要人眼去测。只希望在做类似的Testing时能多想想，尤其是UX设计人员一定要求实现的点。

以上就是我对四种Testing框架或工具的简介，相互比较之后，如果选择在Nodejs环境中使用，首当其冲我推荐Mocha，如果需要在浏览器中运行，那么可以选择Jasmine或者JsTestDriver工具。但是工具的选择并不是提高软件质量的原因，你所编写的高质量Testing才是。要写出高质量的Testing，驱动出可被Testing的代码，必须懂得如何划分task，如何理解Testing技术给软件带来的好处，如何编写高质量的单元Testing等等。这些能力和前端后端无关，他们是需要在Testing领域长期摸索才能练就的本领。希望好学者能饱读书籍，熟能生巧。在下也才刚刚上路。