1. 从零搭建前端开发环境（零）——基础篇：1.npm、git及项目初始化
2. 从零搭建前端开发环境（零）——基础篇：2.webpack生产与开发环境配置
3. 从零搭建前端开发环境（零）——扩展篇：3.jest单测
4. 从零搭建前端开发环境（零）——扩展篇：4.eslint统一代码规范
5. 从零搭建前端开发环境（零）——终极篇：5.构建自己的前端脚手架

注：扩展篇里的内容，并不是建立项目的必要条件，属于可选范围。但是如果项目复杂到了一定程度，终究还是要面对的。

单测在前端并不是特别被重视，毕竟很多结果是可以实实在在看得见的，有时宁可手动一步一步的点，也不愿意去写单测。的确，单测在项目没有一定规模，或者不是有很多人公用的时候，的确显得没有必要，这也是我把它放在《扩展篇》里的原因。但是，作为一个有追求的程序员，我们怎么也不能让它缺了不是。

0、前端测试框架浅谈

目前前端比较流行的测试框架组合是karma + mocha + chai，分别负责覆盖率、测试、断言。当然还有Jasmine、should、power-asset等。而我们今天要用的算是一个后起之秀，jest。它是facebook开源的一个测试框架，自己一个人就干了上面组合的活，稍微配置一下就可以用，比较方便。至于性能，笔者没有太深入的进行过比较，所以也没有什么发言权。jest流行的另一个原因是react的流行，jest + enzyme来测试react组件是目前最流行的组合。闲话少说，进入主题。

1、jest的安装及配置

 

$ npm i -D jest jest-babel

config/jest.config.js

const path = require('path');

module.exports = {
  rootDir: path.resolve(__dirname, '../'),
  collectCoverage: true, // 是否收集测试时的覆盖率信息  
  collectCoverageFrom: [ // 哪些文件需要收集覆盖率信息  
    "src/util/**/*.{js,jsx,mjs}"
  ],
  coverageDirectory: "<rootDir>/test/coverage", // 输出覆盖信息文件的目录  
  coveragePathIgnorePatterns: [ // 统计覆盖信息时需要忽略的文件  
    "/node_modules/"
  ],
  moduleNameMapper: { // 主要用于与webpack的resolve.alias匹配，注意正则写法  
    "^src(.*)$": "<rootDir>/src$1",
    '^util(.*)$': "<rootDir>/src/util$1"
  },
  testMatch: [ // 匹配的测试文件  
    "<rootDir>/test/**/?(*.)(spec|test).{js,jsx,mjs}"
  ],
  testURL: "about:blank", // 运行环境下的url  
  transform: {
    "^.+\\.(js|jsx|mjs)$": "<rootDir>/node_modules/babel-jest"
  },
  transformIgnorePatterns: [ // 转换时需要忽略的文件  
    "[/\\\\]node_modules[/\\\\].+\\.(js|jsx|mjs)$"
  ]
}

package.json中加入命令

  "scripts": {
    "test": "jest --config config/jest.config.js",
    "prod": "webpack --config config/webpack.prod.js",
    "dev": "webpack-dev-server --config config/webpack.dev.js --open"
  },

.babelrc加入test环境的配置，主要是要去掉modules：false

{  
  "presets": [  
    ["env",{ "modules": false }],  
    "stage-2"  
  ],
  "env": {
    "test": {
      "presets": ["env", "stage-2"]
    }
  }
}  

2、单测用例

test/spec/util.spec.js

import { strReverse } from '@util';

describe('# strReverse', () => {
  it('"12345" => "54321"', () => {
    expect(strReverse('12345')).toBe('54321');
  });
});

语法其实比较简单：

 

1. import需要测试的模块、方法
2. describe一个方法的测试块
3. it一条用例，一个describe里通常有多个it
4. expect具体的测试逻辑

参考jest文档，最后运行一下，查看结果。

$ npm test

Done！是不是也没那么复杂。

个人理解，一些需要共享出去的组件、工具等，是一定要写单测的，这样才能够保证质量。另外，如果一个项目想要重构，那么有了单测的话，无疑会减少重构的风险。同时，相应的，写单测也是需要消耗时间的，这当中的效率，还是需要平衡的。

3、配置展示

全部变化可看笔者的github记录，还是很清晰的。

package.json

{
  "name": "demo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "jest --config config/jest.config.js",
    "prod": "webpack --config config/webpack.prod.js",
    "dev": "webpack-dev-server --config config/webpack.dev.js --open"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babel-core": "^6.26.0",
    "babel-loader": "^7.1.4",
    "babel-preset-env": "^1.6.1",
    "babel-preset-stage-2": "^6.24.1",
    "css-loader": "^0.28.11",
    "extract-text-webpack-plugin": "^3.0.2",
    "file-loader": "^1.1.11",
    "html-webpack-plugin": "^3.1.0",
    "jest": "^22.4.3",
    "jest-babel": "^1.0.1",
    "less": "^3.0.1",
    "less-loader": "^4.1.0",
    "postcss-import": "^11.1.0",
    "postcss-loader": "^2.1.3",
    "postcss-url": "^7.3.1",
    "style-loader": "^0.20.3",
    "url-loader": "^1.0.1",
    "webpack": "^3.11.0",
    "webpack-dev-server": "^2.11.2",
    "webpack-merge": "^4.1.2"
  }
}

目录结构

demo  
  |- config/
    |- jest.config.js
    |- webpack.base.js  
    |- webpack.dev.js  
    |- webpack.prod.js  
  |- src/  
    |- assets/  
     |- logo.jpg
    |- util/
      |- index.js
    |- index.css  
    |- index.js  
  |- test/
    |- spec/
      |- util.spec.js
  |- .babelrc  
  |- .gitignore  
  |- .postcssrc.js  
  |- index.html  
  |- package.json