2017 年的 JavaScript Testing 盘点

看，下图是 Facebook 出品的测试框架 Jest 的 logo:
他们的 slogan 标榜了 Jest 是“painless（没有痛点）” 测试，但有人认为 "没有痛点的测试是不存在的"：

因为一般来说 JS 开发者是不太喜欢做网页测试的。JS 测试往往能力有限、搭建测试用例比较难而且效率不高，FaceBook 希望用这个 slogan 吸引到开发者用户。
但其实，只要用对方法，找到合适的测试框架或测试库的组合方式，是能构建出一套覆盖完整且效率很高的方案的。

值得一提的是，在撰写这篇文章的过程中，我发现很多相当优秀的库或者框架，在一些特定的测试场景中它们可能很有用。但可能现在由于各种原因没有再维护了，比如 DalekJS。如果有公司愿意参与维护，复兴这些库就好了。
之后我也许会找机专门开篇讨论这个话题。现在就先专注这篇的内容，讨论讨论圈内正火的测试库吧。

测试类型
想要了解更多关于测试类型的信息，可以访问这三个链接：链接1、链接2、链接3：
总的来看，可以分为下面三种测试类型：
单元测试 (Unit Test) - 通过模拟输入和预测输出的方式测试独立的函数或者类。
集成测试 (Integration Test) - 测试多个模块间的联动是否和期望相同。
功能测试 (Functional Test) - 关注点不在内部实现方式，而是测试产品在真实使用场景（比如在浏览器）中是否可以达到预想的结果。

测试工具的类型
根据功能，测试工具可以被分为下面几类，其中有些专注在一个测试类型上；有些则是像搭积木一样，开发者通过自由搭配不同的工具整合适合项目的测试方法。
即使用一个测试框架可能就能满足当前需求，但出于长远考虑，为了提高扩展性，多数开发者还是会选择自由组合各种工具。

提供测试环境：Mocha, Jasmine, Jest, Karma
提供测试结构：Mocha, Jasmine, Jest, Cucumber
有断言测试：Chai, Jasmine, Jest, Unexpected
生成、展示和监控测试结果：Mocha, Jasmine, Jest, Karma
通过对比生成的组件和数据结构的快照，确保更改是来自前一次运行的：Jest, Ava
提供 Mocks、Spies 和 Stubs：Sinon, Jasmine, enzyme, Jest, testdouble
生成代码覆盖报告：Istanbul, Jest
提供一个浏览器或类浏览器环境，并提供接口可以控制它们的执行场景：Protractor, Nightwatch, Phantom, Casper

现在来详细聊一聊上面提到的各种工具吧：
测试结构 (Testing Structure) 指的是开发者如何组织自己的测试逻辑。常见的 BDD（行为驱动开发 behavior-driven development） 测试结构的代码大概是这样的：
describe( 'calculator', function() { // 内嵌 describe 函数用于描述一个模块describe( 'add', function() { // 期望的表现行为it( 'should add 2 numbers', function() { // 用断言测试预期行为}) })})
断言函数：用于测试运行结果是否如预期的函数，使用人数最多的是下面代码中的前两个库（即 Chai 和 Jasmine）：
// Chai 中设定 expect 值expect(foo).to.be.a( 'string')expect(foo).to.equal( 'bar') // Jasmine 中设定 expect 值expect(foo).toBeString()expect(foo).toEqual( 'bar') // Chai 的断言assert.typeOf(foo, 'string')assert.equal(foo, 'bar') // Jasmine 中的 expect 值expect(foo, 'to be a', 'string')expect(foo, 'to be', 'bar')
TIP： 对 Jasmine 的断言的高级运用，可以看这篇文章。
Spies告诉开发者在应用中或者测试中的函数被调用多少次、在什么情况下被谁调用等信息。这个特性常用在集成测试中，特别是想要测试特定场景下函数的执行情况时。比如在使用应用的某个过程里一个计算逻辑被调用了多少次。
it( 'should call method once with the argument 3', () => { constspy = sinon.spy(object, 'method') spy.withArgs( 3) object.method( 3) assert(spy.withArgs( 3).calledOnce)})
Stubbing 也可以叫 dubbing（类似电影中「替身」的概念）的使用场景是开发者在确定某个模块一定能通过测试时，假设那些函数已经被正确的执行了，然后将某些函数替换成预期值。
如果我们希望在测试时 user.isValid() 总是返回 true，那么你可以这么写：
sinon.stub(user, 'isValid').returns( true) // SinonspyOn(user, 'isValid').andReturns( true) // Jasmine
也支持 promise 语法：
it( 'resolves with the right name', done => { conststub = sinon.stub(User.prototype, 'fetch') .resolves({ name: 'David'}) User.fetch() .then(user => { expect(user.name).toBe( 'David') done() })})
Mocks或者被称为 Fakes假定了某些模块或者某些行为，以确保测试是在已知输入值的情况下进行的。Sinon 就有这个功能，比如模拟服务器和客户端间的交互，保证能迅速得到预期的结果：
it( 'returns an object containing all users', done => { constserver = sinon.fakeServer.create() server.respondWith( 'GET', '/users', [ 200, { 'Content-Type': 'application/json'}, '[{ "id": 1, "name": "Gwen" }, { "id": 2, "name": "John" }]']) Users.all() .done(collection => { constexpectedCollection = [ { id: 1, name: 'Gwen'}, { id: 2, name: 'John'} ] expect(collection.toJSON()).to.eql(expectedCollection) done() }) server.respond() server.restore()});
快照测试适用需要比较预期数据结果和实际结构的场景。比如，下面这段代码模拟了链接组件被渲染后，将结果保存为 JSON 格式以做比较。

本次快照的对比对象是前一次的运行结果。开发者可以观察前后快照是否一致，如果有不一致，能进一步确认两者之间存在的差异是否合理：
it( 'renders correctly', () => { constlinkInstance = ( <Linkpage="http://www.facebook.com">Facebook</Link>)consttree = renderer.create(linkInstance).toJSON() expect(tree).toMatchSnapshot()}) 组合为整体
我们建议尽可能在所有的场景里都用同一种测试工具，包括相同测试结构和语法(2)、断言函数(3)、测试报告和监控(4)。有时候即使只用一种环境配置(1)都可以满足两种以上的测试场景。
根据测试类型按需执行。
单元测试：给每个用例提供对应的模拟输入(6)，确认输出是否如预期(3)，还要使用覆盖率工具(7)检查用例的覆盖情况
集成测试：定义重要的跨模块的内部场景。单元测试相比，集成测试要求开发者需要用到 spies 和 stubs 预估程序的行为，而不是仅仅s是使用断言判断输出 (6)。浏览器或者类浏览器环境可以模拟在多个进程之间的集成测试，以及 UI 上的展示。
功能测试：通过在浏览器或类浏览器环境中，配合 API 的调用模拟用户行为进行测试。