前戏
最近写了一个 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)
transform 就是专门用来匹配各种文件后缀, 然后进行对应的预处理, 你可以理解为 webpack 里的 loader
我在 TS 中引入了. css 文件咋办? 同上
既然有 transform, 那我们任何文件都可以通过 transform 进行预处理了
- transform: {
- '^.+\\.js
如果是 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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
: '<rootDir>/node_modules/babel-jest',如果是 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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
: '<rootDir>/node_modules/ts-jest/preprocessor.js',如果是 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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
:"<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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
: '<rootDir>/node_modules/ts-jest/preprocessor.js',transform 就是专门用来匹配各种文件后缀, 然后进行对应的预处理, 你可以理解为 webpack 里的 loader
我在 TS 中引入了. css 文件咋办? 同上
既然有 transform, 那我们任何文件都可以通过 transform 进行预处理了
- transform: {
- '^.+\\.js
如果是 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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
: '<rootDir>/node_modules/babel-jest',如果是 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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
: '<rootDir>/node_modules/ts-jest/preprocessor.js',如果是 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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
:"<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 的用法或者语法, 希望可以给不知道如何做测试的朋友们一点方向, 自己去尝试找到适合自己项目的才是最好的
刚刚开始可能很难, 无从下手, 成本很大实际上做起来, 其实都是慢慢的套路, 写熟练了后应该会上瘾, 毕竟最后跑完测试的那感觉会让你达到高潮
来源: https://juejin.im/post/5a8a5a0c6fb9a0634e6c99e7