前端如何做单元测试？

测试环境
和后端不同，前端有运行环境的差异性，需要考虑兼容性，如何模拟浏览器环境，如何支持到BOM API的调用，这些都是需要考虑的。可以考虑以下几种测试环境的解决方案：

测试工具
测试框架就是运行测试用例的工具，常见的有Macha、Jasmine、Jest、AVA等等。

断言库主要提供语义化方法，用于对参与测试的值做各种各样的判断。这些语义化方法会返回测试的结果，要么成功、要么失败。Node内置断言库assert，常见的断言库还有有chai.js、should.js。断言库可以支持不同的开发模式，比如chai.js就是一个BDD/TDD模式的断言库。

测试覆盖率工具是用于统计测试用例对代码的测试情况，生成相应的报表，如Istanbul(Jest内置集成)。

Karma是一个测试平台，可以在多种真实浏览器（e.g Chrome Firefox Safari IE等等）中运行JavaScript代码，可以和很多测试框架集成，比如Mocha、Jasmine等等，还可以使用Istanbul自动生成覆盖率报告。

CI/CD
首先先看一张图片，来理解Agile(敏捷开发)、CI(持续集成)，CD(持续交付/部署)和DevOps(开发运维一体化)涵盖的生命周期范围。CI/CD并不等同于DevOps，它们只是DevOps的部分流程中的一种解决方案。

DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。

各个术语涵盖的生命周期范围

持续集成（Continuous Integration）中开发人员需要频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试（通常是单元测试）进行验证。

CI的好处在于可以防止分支偏离主干太久，这种持续集成可以实现产品快速迭代，但是由于要频繁集成，所以需要支持自动化构建、代码检查和测试，实现这些自动化流程是CI的核心。

持续集成

持续交付（Continuous Delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

CD是CI的下一步，它的目标是拥有一个可随时部署到生产环境的代码库。

持续交付

持续部署是持续交付的延伸，实现自动将应用发布到生产环境。

持续部署

公司内部常用的解决方案有：蓝盾DevOps平台、orange-ci、QCI，各花入各眼，详情可以阅读这篇文章CI工具哪家强。

这些CI平台是怎样将git仓库中的代码变动和自动化构建流程相关联起来的呢？答案就是Webhook，它与异步编程中“订阅-发布模型”非常类似，一端触发事件，一端监听执行。

在web开发过程中的Webhook，是一种通过通常的callback，去增加或者改变web page或者web app行为的方法。这些callback可以由第三方用户和开发者维持当前，修改，管理，而这些使用者与网站或者应用的原始开发没有关联。Webhook这个词是由Jeff Lindsay在2007年在计算机科学hook项目第一次提出的。

Webhooks是”user-defined HTTP回调”。它们通常由一些事件触发，这里可以查看GitHub上面支持的Event类型，比如git push、fork等等，也就是说这些代码托管平台首先要支持Webhook的功能。
当事件发生时，源网站可以发起一个HTTP请求到Webhook配置的URL。通常这里配置的URL指向某个CI系统，这意味着当git仓库中“订阅”的事件发生时，CI系统可以收到通知。
CI系统在收到通知后就可以触发build等流程。

CI自动化构建只是应用Webhook的一个案例，Webhook的应用远不止这些，由于webhook使用HTTP协议，因此可以直接被集成到web service，有时会被用来构建消息队列服务，例如一些RESTful的例子：IronMQ和RestMS。

我们的项目构建现状

介绍完了前端工程化的一些概念和技术后，下面结合我们团队中的具体项目具体分析。

1.现状分析

这是目前团队移动端基础库的项目结构：主要有9个模块，其中3个UI组件依赖框架。

基础库项目结构

模块化

我们团队在移动端基础库的开发中，最初采用的是IIFE模式。从严格意义上来说，这并不是一种标准的模块化方式，只是通过闭包实现了私有数据，将数据和行为封装到一个函数内部，通过给全局对象window.M添加属性来向外暴露接口，我们无法确认每个模块间的依赖关系，模块合并时还要关注依赖顺序。在新的方案中，我们引入了ES6的模块化标准来解决这个问题。

重复开发，复制粘贴

由于业务特点，对于一些快速上线的活动页使用Zepto库，而对常驻页面进行了技术升级，社交团队使用了Preact框架，这导致基础库的开发有了两个版本，分别在不同的代码仓库维护，但实际上二者90%+的代码都是一样的，仅仅是三个UI组件不同。在基于TSW的同构直出项目中，有些基础库方法又要在node端执行，这个时候也是复制粘贴了一份m.js放到了该项目目录中。在新的方案中，我们使用差异化的构建在一份代码仓库中分别构建出多个版本。

组件css的问题

对于组件的样式，我们是有专门的重构组进行开发维护的，他们遵循BEM规范，开发组件的时候当字符串引入：

var css ='.qui_dialog__mask{position:fixed;top:0;left:0;bottom:0;right:0;}...';
appendToHead(css);

这种模式对CSS的开发维护很不友好，虽然我们不需要关注样式的细节，但还是每次要把重构发给我们的.css文件中的样式copy出来。新方案中，我们引入CSS module的方案。

2.技术选型

主流构建工具
构建工具的选择，主要对比了Webpack4、Rollupjs和Parcel，因为基础库的构建文件只有js，而且从构建体积来说，rollupjs是有绝对优势的，所以选择了rollupjs。

主流构建工具对比

CSS模块化
由于CSS in JS需要引入额外的依赖，在对比了CSS Module和CSS in JS后，我们选择CSS Module的方案。

CSS模块化方案对比

单元测试框架
单元测试框架我们选择了Jest，主要是因为开箱即用，不需要再引入断言库，生态也很好，较多用于React项目，而且组内的UI自动化测试系统是支持Jest的，这篇文章Migrating from Mocha to Jest中介绍了Airbnb的尝试。

单元测试框架对比

Lint方案
由于接入了CI系统进行lint自动化检查，为了减少“无效”的commit，我们选择了husky+lint-staged来进行本地代码提交前的lint。

Lint方案

工作流和CI？
各种工作流中，首先需要在各自的开发分支进行开发测试，然后将代码合并到追踪生成环境的长期分支进行持续地发布部署，这意味着对这个长期分支要有完善的自动化测试能力，因为谁也不能保证merge的代码就一定不会有问题，目前新的方案引入了单元测试，对UI组件引入了基于puppeteer的截图测试，但一些功能缺乏在更多设备、更多平台上的自动化验证，因此我们认为在自动化测试方面的建设还不是非常完善，所以新方案接入了CI，但是对发布外链基础库music.js这种会直接影响到全量业务的并没有接入，还是使用ARS发布，除非紧急bug，其他的代码更改会在测试环境验证一段时间(一般2-3天)后才会发布外网。

我们的工程化实践

1.构建方案

新旧方案对比
首先可以看一下新旧构建方案的对比，在新方案中推广使用ES6，增加了对代码质量的控制：代码检查+单元测试，并接入了CI系统。

新旧方案对比

打包方案
这是我们整体的打包方案，核心是一份源码开发维护，通过构建工具的差异化配置实现多种版本的构建。

打包方案

开发流程
这是整体的开发流程，本地开发使用package.json管理项目依赖，规范代码格式，接入单元测试；提交之前git hook设置保证代码检查和测试通过后才能提交成功；使用QCI自动进行项目的构建、检查和测试，通过后将JSDOC文档推送到文档服务器，并发布npm包，外链js还是使用ars发布。

开发流程

2.UI组件开发和文档

我们选择react-styleguide作为UI组件开发调试工具以及文档生成器，这是一个组件的MD文件示例：

组件式引入

可以提前插入dom结构，如果浮层中有图片的话会先加载；
属性中的 visible 控制组件是否可见。

import Button from '../../basic/Button/Button'
import QMDialog from './QMDialog';

class QMDialogExample extends React.Component {
    constructor(props) {
        super(props);
        this.state = {visible1: false}
    }


    render() {
        const {visible1} = this.state;
        return (

            <div>
                <Button onClick={() => {
                    this.setState({
                        visible1: true
                    })
                }}>基本使用</Button>
                <Button onClick={() => {
                    this.setState({
                        visible2: true
                    })
                }}>带头图的浮层</Button>
                <Button onClick={() => {
                    this.setState({
                        visible3: true
                    })
                }}>传入一个react节点</Button>

                <QMDialog
                    visible={visible1}
                    title="QQ音乐"
                    message="这是一段描述"
                    btn={'我知道了'}
                    handleTap={index => {
                        if(index === -1) {
                            this.setState({
                                visible1: false
                            })
                        } else {
                            console.log('我知道了按钮被点击，index=', index)
                        }
                    }}
                />
            </div>

        )
    }
}
<QMDialogExample />

react-styleguide会根据组件的源码和这个md文件生成文档和demo，开发调试阶段支持webpack配置HMR，非常方便。

demo文档截图

3.Jest单元测试

Jest可以设置全局的Setup，会在所有test执行之前运行，也可以设置全局Teardown，会在所有test执行完毕之后运行，比如这里就可以设置一些测试需要的Global对象、运行环境等等。describe可以将测试用例进行分组，beforeEach、afterEach、beforeAll、afterAll这些方法可以定义在测试用例之前或者之后运行的方法。

测试方案
根据上面介绍的打包方案和业务特点，基础库需要分别运行在node端和浏览器端，因此需要考虑到不同运行环境下的测试结果。

浏览器端

module.exports = {
  clearMocks: true,
  coverageDirectory: "jest-coverage/coverage-music-node",
  preset: null,
  rootDir: '../../',
  testEnvironment: "jest-environment-jsdom-fourteen",
  testMatch: [
    "**/tests/music-node/**/*.test.[jt]s?(x)",
  ],
  testURL: "https://y.qq.com/m/demo.html",
  transformIgnorePatterns: []
};

Node端
node端和浏览器端的不同在于运行环境testEnvironment不同，jest提供jest-environment-node，我们为node端单独配置了music-node.jest.config.js。

UI组件
Jest支持对React App的测试，可以采用截图测试(Snapshot Testing)、模拟DOM操作(DOM Testing)等方法详见文档。在组件文档和demo这一章节中我们已经有了组件示例，并构建了文档页，可以直接接入团队的自动化测试系统，结合使用puppeteer进行截图对比。

下面是对QMDialog组件的测试用例，首先准备一张基准图片，然后写测试流程：打开页面——点击按钮触发组件——截图对比。screeshotDiff方法的实现参考了这篇KM文件通过puppeteer实现页面监控，图片diff核心算法由pixelmatch库实现。

const iPhone = devices['iPhone 6'];
await page.emulate(iPhone);

await log("进入页面");
await page.goto('http://[host]/reactui/index.html#/QMDialog', {
    waitUntil: 'load'
});

await timeout(3000);
let dom = await page.$('#QMPreload-container .rsg--preview-35 .button');

await dom.click();

await timeout(200)
let diff = await screenshotDiff({
    img: 'https://y.gtimg.cn/music/common/upload/t_cm3_photo_publish/1677163.png'
});

if (diff > 10) {
    fail();
   return;
}

success();

这是一次测试运行结果，从左到右依次是：基准图、测试截图、diff结果图，screeshotDiff根据第三张图片返回差异点的占比，由于QMPreload组件的特点，加载进度受网络影响，设置阈值为10%，即只要差异率在10%以内就可以认为是正常的。

QMPreload测试结果

和上面QMPreload不同，对QMDialog组件的判断则是需要差异值为0，如下面第三张图所示，没有差异点。

QMDialog测试结果

mock
这是我们参照官网的文档接入的mock示例，这里需要注意__mock__的目录结构，详见文档。

.
├── config
├── src
│   ├── music
│   │   ├── utils
│   │   │   ├── __mock__
│   │   │      └── loadUrl.js
│   │   └── loadUrl.js
├── node_modules
├── ...
└── tests

loadURL方法用来动态加载js，使用jest.fn().mockImplementation对loadUrl进行mock，并mock了window.pgvMain和window.pgvSendClick。

export const loadUrl = jest.fn().mockImplementation((url, callback) => {
    if (/ping.js/.test(url)) {
        let pvCount = 0;
        window.pgvMain = jest.fn().mockImplementation( (p1, p2) => {
            expect(p1).toBe('');
            expect(p2.virtualDomain).toBe('y.qq.com');
            if (pvCount === 1) {
                expect(p2.ADTAG).toBe('all');
            }
            pvCount++;
        })
        window.pgvSendClick = jest.fn().mockImplementation( (p) => {
            expect(p.hottag).toEqual(expect.stringContaining('.android'));
        });
    }
    callback();
});

export default loadUrl;

因为使用了ES module的import，需要jest.mock对整个模块进行mock。对于mock的函数才能调用toHaveBeenCalledTimes的断言。

import tj from '../../src/music/tj';
import loadUrl from '../../src/music/utils/loadUrl'

jest.mock('../../src/music/utils/loadUrl');

describe('【tj.js】点击上报', () => {
    test('tj.pv tj.sendClick', () => {
        expect(typeof window.pgvMain).toBe('undefined');
        expect(loadUrl).toHaveBeenCalledTimes(0);
        tj.pv();
        expect(loadUrl).toHaveBeenCalledTimes(1);
        expect(typeof window.pgvMain).toBe('function');
        expect(window.pgvMain).toHaveBeenCalledTimes(1);
        tj.sendClick();
        tj.sendClick('tjtag.click');
        window.tj_param = {
            ADTAG: 'all'
        }
        tj.pv();
        expect(loadUrl).toHaveBeenCalledTimes(1);
        expect(window.pgvSendClick).toHaveBeenCalledTimes(1);
    });
})

测试覆盖率
这是某一次的测试报告，上面有每个模块详细的测试覆盖率。为了便于对各个模块灵活处理，我们将每个函数细分拆成一个文件，如下面的src/music/type目录下的各个文件。

测试覆盖率-1

测试覆盖率-2

测试覆盖率-3

通过单元测试发现的代码bug
这些都是我们通过单元测试发现的之前一些函数的bug，仅举例一部分：

4.一些Tips

声明pkg.module
声明pkg.module可以让构建工具利用到ES Moudle的很多特性来提高打包性能，比如利用Tree Shaking的机制减少文件体积，这篇文章package.json中的Module字段是干嘛的有详细介绍。

sideEffects
Tree Shaking可以在构建的时候去除冗余代码，减少打包体积，但这是一个非常危险的行为，在webpack4中，可以在package.json中明确声明该包/模块是否包含sideEffects(副作用)，从而指导webpack4作出正确的行为。如果在package.json中设置了sideEffects: false，webpack4会将import {a} from 'moduleName’转换为import a from ‘moduleName/a’，从而自动修剪掉不必要的import，作用机制同babel-plugin-import。这个功能亲测是很有效的

对于rollupjs来说，有时候Tree Shaking并不有效，这是官网的一段解释，大意就是静态代码分析很难，为了安全rollupjs可能会无法应用Tree Shaking，这个时候建议最好还是明确import的PATH，这里可以结合适应上面的babel-plugin-import插件。

Tree-Shaking Doesn't Seem to Be Working

插件

@babel/plugin-transform-runtime

这个插件可以避免每一个js文件分别引入胶水代码，而是整个构建文件引入一份胶水代码，减少代码体积。

eslint-friendly-formatter

对eslint的错误输出进行格式化，方便查看和定位问题。

babel-plugin-transform-react-remove-prop-types

由于运行时的性能原因，RN已经在production模式下移除了PropTypes，我们引入这个babel插件在生产模式中移除组件属性的类型校验相关的代码。

—noConﬂict
在将外链js用rollupjs构建成umd规范的时候，我们设置了–noConflict，可以解决全局变量M冲突的问题，类似于jQuery.noConflict()。

(function (global, factory) {
    typeof exports === 'object' && typeof module !== 'undefined' ?
        factory(exports) :
        typeof define === 'function' && define.amd ?
            define(['exports'], factory) :
            (global = global || self, (function () {
                var current = global.M;
                var exports = global.M = {};
                factory(exports);
                exports.noConflict = function () {
                    global.M = current;
                    return exports;
                };
            }())
);

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/INlxjk4DnBFZynmbUkYGJA

创作场景

QQ 音乐商业化 Web 团队：前端工程化实践总结（三）