前端单元测试初探

原文发于个人博客:https://github.com/hwen/blogS...html

要不要写单测?

关于这个 cnode 上就有个颇有意思的讨论前端

作个调查,你的 Node 应用有写单测吗?node

看完这个应该会有结论?若是没有,就回帖跟别人探讨下~webpack

测试

测试有分为git

  • 单元测试(单测)github

  • 集成测试web

  • 系统测试express

主要区别是单测倾向于测试模块内部运行逻辑及功能,集成测试倾向于模块间互相组合跟调用的测试。
系统测试(固然你要说,还有自动化测试)是对整个系统的测试,主要由测试人员而非开发人员负责。后端

本文只讨论单测的范畴,对集成测试有兴趣的话,能够看下 Vue 的集成测试代码。api

前端单测现状

测试本质上就是假定一个输入,而后判断获得预期的输出。而前端与后端相比,夹杂着浏览器 DOM 操做,异步请求,
浏览器兼容性等方面的。要我来讲,比后端写单测要麻烦多了。。。

不过如今前端的单测已经发展得比较完善了,已经有一套比较完整的工具链,来完成各类需求。

单测工具链

框架

目前比较流行的测试框架有:

  • jasmine: 自带断言(assert),mock 功能

  • mocha:框架不带断言和mock功能,须要结合其余工具。mocha 是 tj 大神写的(tj 就是那个写了express、koa、n、co、ejs的人。。。)

用得比较多的就上面两个,还有一些用得比较少的,好比 Qunitintern

框架的实现原理其实就是检测内部运行的代码是否有抛出异常。而断言库若是没有获得预期的输入时,就会抛出异常,给框架检测到。

PS.想要学 mocha 和单测写法,最好的资源就是 express 框架的测试代码(狼叔推荐,亲测很不错)

断言库

  • chai:目前比较流行的断言库,支持 TDD(assert),BDD(expect、should)两种风格

  • shouldjs:也是 tj 写的,说实话我比较喜欢这个,可是有坑。。。后面会说到。。。

  • expectjs:基本是 shouldjs 的缩水版

  • assert:node 的核心模块,node 环境能够直接使用

mock 库

  • sinon.js:只用过这个,其余不大清楚。不过这个是目前最多人用的,基本够了。支持 spies, stub, fake XMLHttpRequest, Fake server, Fake time,很强大

测试集成工具

  • karma:Google Angular 团队写的,功能很强大,有不少插件

  • buster.js: 这个支持 node 环境,但目前还在 beta 版(2017/11/4,版本0.7)。官网

半小时上手单测

(并非学会,就是这么耿直 _(:з)∠)_,手是谁???)

使用的是:karma + mocha + chai + sinon(若是以前没了解过这几个,能够边写边看文档,这样学会快不少)

完整的例子能够在这里找到:GitHub 项目
建议把项目 clone 下来本身跑一遍,而后能够本身加一些特效(啊,不对,是代码才对。。。

测试 DOM

详细代码,及配置见 源码

it('test dom', () => {
  const div = document.getElementById('test')

  const content = div.innerHTML
  content.should.be.equal('here')

  setDivContent()
  const after = div.innerHTML
  after.should.be.equal('hallo world')
})

测试异步请求

it('test async', done => {
  getTopics()
    .then(res => {
      res.success.should.be.equal(true)
      done()
    })
    .catch(err => {
      info(err)
      done(err)
    })

})

调试技巧

调试技巧之一:善用 only

当你的单元测试越写越多时,想测试新写的单测是否正确时,能够用 mocha 的 only
这样作的好处有二:第一屏蔽其余测试可使测试速度变得更快,第二屏蔽其余测试,能够在你新写的测试错误时
肯定这个错误不是被其余测试所影响致使的。

用法

describe.only('something', function() {
  // 只会跑包在里面的测试
})

或者

it.only('do do', () => {
  // 只会跑这一个测试
})

调试技巧之二:善用 debug

要开启 debug 的话,先在 karma.conf.jssingleRun 改为 false
而后,看图(懒得打字了 (:з)∠)

图片描述

覆盖率

生成覆盖率报告也是至关简单,不过有个要注意的地方就是
如今前端代码不少都是通过 webpackbabel 编译的,生成的代码会多了不少二外的代码

要解决这个问题使用babel-plugin-istanbul来替代karma-coverage就能够了

preprocessors: {
      'src/**/*.js': ['webpack', 'coverage'],
      'test/*.test.js': ['webpack']
    }

将 karma-coverage 去掉,变成

preprocessors: {
      'src/**/*.js': ['webpack'],
      'test/*.test.js': ['webpack']
    }

而后在 webpack 配置添加 istanbul 插件

use: {
    loader: 'babel-loader',
    options: {
      plugins: ['istanbul']
    }
  }

最后能够生成覆盖率报告

cover1
cov2

另外有不少工具能够对生成的覆盖率报告进行进一步的分析,好比最多见的
你会在 Github 上常常见到的图标

cov-icon

这个就是利用报告里的lcovonly分析生成的

coverageReporter: {
  dir: 'test/coverage/',
  reporters: [
    { type: 'html', subdir: 'report-html' },
    { type: 'lcovonly', subdir: '.', file: 'report-lcovonly.txt' },  // 这里,你能够重命名 file
    { type: 'text-summary', subdir: '.', file: 'text-summary.txt' }
  ]
}

一些坑

  • 测试时若是有涉及浏览器事件(addEventListener),记得测试完移除掉,否则会对其余的测试形成影响(afterEach -> removeEventListener)

  • mocha 里使用箭头函数须要注意,由于箭头函数的 this 指向是静态的,因此 this 并不指向 mocha(没有 mocha 上下文)

  • 上面有说到,若是测试的是通过编译的代码,须要进行一些配置,目前的办法是用babel-plugin-istanbul代替karma-cover来检测覆盖率

补充

前面有说到,为何不用 should.js??由于若是你用 ES6 的语法写单测(webpack 编译),用 import should-sinon 会报错。。(是否是由于 tj 大神写完东西不喜欢维护的习惯致使should.js支持性很差???)

相关文章
相关标签/搜索