使用Jest对原生TypeScript项目进行UI测试

前戏

最近写了一个 wechat-colorpicker 小项目。 主要是为了练习下TS。既然写了一个小库，我就想着顺便学下如何写测试吧，这是一件蛮有意思的事情。

从选型到搭建环境，前先后后用了近2个小时。不得不说一个合格的前端必然是一个合格的配置工程师。再次列举下，这个项目中所须要搭建配置的工具。

• webpack.config 自动编译ts+css
• tsconfig.config ts的配置文件
• tslint.json tslint的配置文件
• jest.config 配置jest
• .babelrc jest解析js时还会须要用到的插件
• circle.yml CircleCI 配置文件

若是你们有什么不懂的，自行百度

Jest + TS 入门

第一个问题，我项目都是TS写的，天然会有 import 这样的语法怎么办？

经过官网的Getting started 咱们能够在最下方找到 ts-jest 不难理解，咱们须要配的其实就是jest加载到什么样类型的文件，使用什么预处理来处理文件。

transform: {
    '.*\\.(ts)$': '<rootDir>/node_modules/ts-jest/preprocessor.js',
},
复制代码

transform 就是专门用来匹配各类文件后缀，而后进行对应的预处理，你能够理解为webpack里的loader

我在TS中引入了.css文件咋办？同上

既然有transform，那咱们任何文件均可以经过transform进行预处理了。

transform: {
    '^.+\\.js$': '<rootDir>/node_modules/babel-jest',
    '.*\\.(ts)$': '<rootDir>/node_modules/ts-jest/preprocessor.js',
    '^.+\\.(css)$':"<rootDir>/node_modules/jest-css-modules"
},
复制代码

若是是js文件我经过babel-jest处理，css则使用jest-css-modules。假如没有这些配置，那import了你的库，库里有引入了高特性的js文件，或者css文件就会编译报错。

关于rootDir

在进行技术选型的过程当中，我看了最新版本的vue-cli里推荐用哪些框架进行测试，一个是jest，还一个是krama+mocha。 我选择了jest，jest自己是fb出的，对于react很是友好。自己也作了许多环境上的封装切换jsdom环境或者node环境很是方便。我最后选择了这个。

刚刚开始看vue-cli里的jest配置我是拒绝的，第一个最显眼的关键字就是<rootDir>这种像XML得东西。可是你慢慢静下心来去理解就很容易了，其实就是一个basePath的感受。咱们能够看下文档怎么说 rootDir

个人目录以下

--- __test__
    jest.config.js
--- dist
--- node_modules
--- src

复制代码

//jest.config.js
module.exports = {
      rootDir: path.resolve(__dirname, '../'),
}
复制代码

<rootDir>其实就表明根目录了

setupFiles 选项

setupFiles是一个AOP的配置，我以为这个很是好用！由于jest是经过jsdom是模拟了一个document的执行环境，那必然还有不少多是没有的，好比localStorage，那咱们能够经过该配置来设置咱们启动前，须要加载什么，好比vue-cli中就是设置了Vue.config.productionTip = false，而咱们可让环境支持localStorage。

setupFiles: ["jest-localstorage-mock"]
复制代码

不难发现，其实jest的生态仍是很丰富的，我本次遇到的问题谷歌几个关键字很快都能解决

UI Test 该怎么写？

test应该是像纯函数同样保证输入输出都是同样的，UI test一方面与Dom耦合，另外一方面又用户交互耦合，那具体应该怎么写呢？

思路是：模拟用户操做，再经过Dom进行判断是否渲染正确。

好比这个实例化的测试，咱们能够测试是否初始化是否正常，经过jquery来辅助判断

// 实例化测试
import WeChatColorPicker from '../src';
import $ from 'jquery';

export function newInstance() {
  document.body.innerHTML = `<div id="container"></div>`;
  return new WeChatColorPicker(pickerOptions);
}

const baseColorArr = [ ... ];

test('test new instance', () => {
  const instance = newInstance();
  expect(instance.baseComponent.baseColorArr).toEqual(baseColorArr);
  expect($('.wechat-colorpicker')).not.toBeNull();
});

复制代码

好比这个是点击【基本色】【更多颜色】咱们会切换class，那就能够像这样

// tab class切换的交互测试
import $ from 'jquery';
import { newInstance } from './utils';

describe('change tab test', () => {
  newInstance();
  test('use base color', () => {
    $('.wechat-picker-box p i').eq(0).click();
    expect($('.wechat-colorpicker').hasClass('base-color')).toBe(true);
  });

  test('use picker', () => {
    $('.wechat-picker-box p i').eq(1).click();
    expect($('.wechat-colorpicker').hasClass('more-color')).toBe(true);
  });
});
复制代码

是否是忽然就以为很是简单了？而且是惟一性的，测试用例可靠性也有保障。 以后咱们就只须要配合一个CI，每次提交前跑一边咱们的测试代码，全部用例测试成功便可pr，不然直接被拒绝。

写完了测试，给咱们的jest.config 多加一行配置，来生成咱们的测试报告(Jest内置了istanbul)

module.exports = {
  // ...
  collectCoverage: true,
  // ...
}
复制代码

接着执行下 npm t 查看测试结果以下

• % Stmts 是语句覆盖率（statement coverage）：是否每一个语句都执行了？
• % Branch 分支覆盖率（branch coverage）：是否每一个if代码块都执行了？
• % Funcs 函数覆盖率（function coverage）：是否每一个函数都调用了？
• % Lines 行覆盖率（line coverage）：是否每一行都执行了？

更多测试用例前往 >>> repo-wechat-colorpicker <<< 查看

CricleCI（番外篇）

咱们能够经过CI的工具来完善咱们的wordflow，在这我选用了CricleCi。进入官网咱们直接github登入后，setup 咱们的项目。

而后根据它的推荐走，在咱们项目根目录添加一个cricle.yml，复制黏贴它的推荐配置便可。

而后咱们push测试一下，在这里我写错了个人文件路径，因此构建报错了。

从新修复了问题后，就能够正常运行工做了。

因为本文不是重点介绍CI，这里就不过多展开了，有兴趣的朋友能够本身摸索下

后面真的没有了

至此，你应该对前端UI测试应该大体有一个宏观的了解。

本文没有过多得介绍Jest的用法或者语法，但愿能够给不知道如何作测试的朋友们一点方向，本身去尝试找到适合本身项目的才是最好的。

刚刚开始可能很难，无从下手，成本很大。实际上作起来，其实都是慢慢的套路，写熟练了后应该会上瘾，毕竟最后跑完测试的那感受会让你达到高潮。