淘宝客建立网站,二维码生成器网页版,海南网站建设案例,怎样申请一个网站前言
对于现在的前端工程#xff0c;一个标准完整的项目#xff0c;通常情况单元测试是非常必要的。但很多时候我们只是完成了项目而忽略了项目测试。我认为其中一个很大的原因是很多人对单元测试认知不够#xff0c;因此我写了这边文章#xff0c;一方面期望通过这篇文章…前言
对于现在的前端工程一个标准完整的项目通常情况单元测试是非常必要的。但很多时候我们只是完成了项目而忽略了项目测试。我认为其中一个很大的原因是很多人对单元测试认知不够因此我写了这边文章一方面期望通过这篇文章让你对单元测试有一个初步认识。另一个方面希望通过代码示例让你掌握写单元测试实践能力。
前端为什么需要单元测试
必要性JavaScript 缺少类型检查编译期间无法定位到错误单元测试可以帮助你测试多种异常情况。
正确性测试可以验证代码的正确性在上线前做到心里有底。
自动化通过 console 虽然可以打印出内部信息但是这是一次性的事情下次测试还需要从头来过效率不能得到保证。通过编写测试用例可以做到一次编写多次运行。
保证重构互联网行业产品迭代速度很快迭代后必然存在代码重构的过程那怎么才能保证重构后代码的质量呢有测试用例做后盾就可以大胆的进行重构。
现状
下面是一份抽样调查片段抽样依据如下
向 200 名相关者发出在线问卷调查其中 70 人回答了问卷中的问题前端人数占 81.16%如果你有兴趣的话也可以帮我填一下调查问卷 (https://www.wjx.cn/vm/Ombu9q1.aspx)
数据收集日期2021.09.21—2021.10.08
目标群体所有开发人员
组织规模不到 50 人50 到 100人 100人以上
你执行过 JavaScript 单元测试吗 调查中的另一个有趣的见解是在大型组织中单元测试更受欢迎。其中一个原因可能是由于大型组织需要处理大规模的产品以及频繁的功能迭代吧。这种持续的迭代方式迫使他们进行自动化测试的投入。更具体地说单元测试有助于增强产品的整体质量。 另外报告显示超 80% 人认为单元测试可以有效的提高质量超 60% 人使用过 Jest 去编写前端单元测试超 40% 的人认为单元测试覆盖率是重要的且覆盖率应该大于 80%。
常见单元测试工具
目前用的最多的前端单元测试框架主要有 Mocha (https://mochajs.cn/)、Jest (https://www.jestjs.cn/)但我推荐你使用 Jest因为 Jest 和 Mocha 相比无论从 github starts issues 量npm下载量相比都有明显优势。
github stars 以及 npm 下载量的实时数据参见jest vs mocha (https://www.npmtrends.com/jest-vs-mocha) 截图日期为 2021.11.25
Github stars issues npm 下载量
Jest 的下载量较大一部分原因是因为 create-react-app 脚手架默认内置了 Jest, 而大部分 react 项目都是用它生成的。 从 github starts issues 以及 npm 下载量角度来看Jest 的关注度更高社区也更活跃
框架对比 Mocha 生态好但是需要较多的配置来实现高扩展性
Jest 开箱即用
比如对 sum 函数写用例
./sum.js function sum(a, b) {return a b;}module.exports sum;
Mocha Chai 方式
Mocha 需要引入 chai 或则其他断言库去断言, 如果你需要查看覆盖率报告你还需要安装 nyc 或者其他覆盖率工具
./test/sum.test.js const { expect, assert } require(chai);const sum require(../sum);describe(sum, function() {it(adds 1 2 to equal 3, () {assert(sum(1, 2) 3);});}); Jest 方式
Jest 默认支持断言同时默认支持覆盖率测试
./test/sum.test.js const sum require(./sum);describe(sum function test, () {it(sum(1, 2) 3, () {expect(sum(1, 2)).toBe(3);});// 这里 test 和 it 没有明显区别it 是指: it should xxx, test 是指 test xxxtest(sum(1, 2) 3, () {expect(sum(1, 2)).toBe(3);});}) 可见无论是受欢迎度和写法上Jest 都有很大的优势因此推荐你使用开箱即用的 Jest
如何开始
1.安装依赖
npm install --save-dev jest2.简单的例子
首先创建一个 sum.js 文件
./sum.js function sum(a, b) {return a b;}module.exports sum;
创建一个名为 sum.test.js 的文件这个文件包含了实际测试内容
./test/sum.test.js const sum require(../sum);test(adds 1 2 to equal 3, () {expect(sum(1, 2)).toBe(3);});
将下面的配置部分添加到你的 package.json 里面 {scripts: {test: jest},}
运行 npm run test jest 将打印下面这个消息 3.不支持部分 ES6 语法
nodejs 采用的是 CommonJS 的模块化规范使用 require 引入模块而 import 是 ES6 的模块化规范关键字。想要使用 import必须引入 babel 转义支持通过 babel 进行编译使其变成 node 的模块化代码
如以下文件改写成 ES6 写法后运行 npm run test将会报错
./sum.js export function sum(a, b) {return a b;}
./test/sum.test.js import { sum } from ../sum;test(adds 1 2 to equal 3, () {expect(sum(1, 2)).toBe(3);}); 为了能使用这些新特性我们就需要使用 babel 把 ES6 转成 ES5 语法
解决办法
安装依赖
npm install --save-dev babel/core babel/preset-env根目录加入.babelrc
{ presets: [babel/preset-env] }再次运行 npm run test 问题解决 原理
jest 运行时内部先执行( jest-babel )检测是否安装 babel-core然后取 .babelrc 中的配置运行测试之前结合 babel 先把测试用例代码转换一遍然后再进行测试
4.测试 ts 文件
jest 需要借助 .babelrc 去解析 TypeScript 文件再进行测试
安装依赖
npm install --save-dev babel/preset-typescript**改写 **.babelrc
{ presets: [babel/preset-env, babel/preset-typescript] }为了解决编辑器对 jest 断言方法的类型报错如 test、expect 的报错你还需要安装
npm install --save-dev types/jest./get.ts /*** 访问嵌套对象避免代码中出现类似 user user.personalInfo ? user.personalInfo.name : null 的代码*/export function getT(object: any, path: Arraynumber | string, defaultValue?: T) : T {const result path.reduce((obj, key) obj ! undefined ? obj[key] : undefined, object);return result ! undefined ? result : defaultValue;}
./test/get.test.ts import { get } from ./get;test(测试嵌套对象存在的可枚举属性 line1, () {expect(get({id: 101,email: jackdev.com,personalInfo: {name: Jack,address: {line1: westwish st,line2: washmasher,city: wallas,state: WX}}}, [personalInfo, address, line1])).toBe(westwish st);}); 运行 npm run test 5.持续监听
为了提高效率可以通过加启动参数的方式让 jest 持续监听文件的修改而不需要每次修改完再重新执行测试用例
改写 package.json
scripts: { test: jest --watchAll },效果 5.生成测试覆盖率报告
什么是单元测试覆盖率 单元测试覆盖率是一种软件测试的度量指标指在所有功能代码中完成了单元测试的代码所占的比例。有很多自动化测试框架工具可以提供这一统计数据其中最基础的计算方式为
单元测试覆盖率 被测代码行数 / 参测代码总行数 * 100%如何生成
加入 jest.config.js 文件 module.exports {// 是否显示覆盖率报告collectCoverage: true,// 告诉 jest 哪些文件需要经过单元测试测试collectCoverageFrom: [get.ts, sum.ts, src/utils/**/*],}
再次运行效果 参数解读
设置单元测试覆盖率阀值
个人认为既然在项目中集成了单元测试那么非常有必要关注单元测试的质量而覆盖率则一定程度上客观的反映了单测的质量同时我们还可以通过设置单元测试阀值的方式提示用户是否达到了预期质量。
jest.config.js 文件 module.exports {collectCoverage: true, // 是否显示覆盖率报告collectCoverageFrom: [get.ts, sum.ts, src/utils/**/*], // 告诉 jest 哪些文件需要经过单元测试测试coverageThreshold: {global: {statements: 90, // 保证每个语句都执行了functions: 90, // 保证每个函数都调用了branches: 90, // 保证每个 if 等分支代码都执行了},},
上述阀值要求我们的测试用例足够充分如果我们的用例没有足够充分则下面的报错将会帮助你去完善 6.如何编写单元测试
下面我们以 fetchEnv 方法作为案例编写一套完整的单元测试用例供读者参考
编写 fetchEnv 方法
./src/utils/fetchEnv.ts 文件 /*** 环境参数枚举*/enum IEnvEnum {DEV dev, // 开发TEST test, // 测试PRE pre, // 预发PROD prod, // 生产}/*** 根据链接获取当前环境参数* param {string?} url 资源链接* returns {IEnvEnum} 环境参数*/export function fetchEnv(url: string): IEnvEnum {const envs [IEnvEnum.DEV, IEnvEnum.TEST, IEnvEnum.PRE];return envs.find((env) url.includes(env)) || IEnvEnum.PROD;} 编写对应的单元测试
./test/fetchEnv.test.ts 文件 import { fetchEnv } from ../src/utils/fetchEnv;describe(fetchEnv, () {it (判断是否 dev 环境, () {expect(fetchEnv(https://www.imooc.dev.com/)).toBe(dev);});it (判断是否 test 环境, () {expect(fetchEnv(https://www.imooc.test.com/)).toBe(test);});it (判断是否 pre 环境, () {expect(fetchEnv(https://www.imooc.pre.com/)).toBe(pre);});it (判断是否 prod 环境, () {expect(fetchEnv(https://www.imooc.prod.com/)).toBe(prod);});it (判断是否 prod 环境, () {expect(fetchEnv(https://www.imooc.com/)).toBe(prod);});}); 执行结果 7.常用断言方法
关于断言方法有很多这里仅摘出常用方法如果你想了解更多你可以去 Jest 官网 API (https://www.jestjs.cn/docs/expect) 部分查看
.not 修饰符允许你测试结果不等于某个值的情况
./test/sum.test.js import { sum } from ./sum;test(sum(2, 4) 不等于 5, () {expect(sum(2, 4)).not.toBe(5);}) ./src/utils/userInfo.js export const getUserInfo () {return {name: moji,age: 24,}}
./test/userInfo.test.js import { getUserInfo } from ../src/userInfo.js;test(getUserInfo()返回的对象深度相等, () {expect(getUserInfo()).toEqual(getUserInfo());})test(getUserInfo()返回的对象内存地址不同, () {expect(getUserInfo()).not.toBe(getUserInfo());})
.toHaveLength 可以很方便的用来测试字符串和数组类型的长度是否满足预期
./src/utils/getIntArray.js export const getIntArray (num) {if (!Number.isInteger(num)) {throw Error(getIntArray只接受整数类型的参数);}return [...new Array(num).keys()];};
./test/getIntArray.test.js ./test/getIntArray.test.jsimport { getIntArray } from ../src/utils/getIntArray;test(getIntArray(3)返回的数组长度应该为3, () {expect(getIntArray(3)).toHaveLength(3);})
.toThorw 能够让我们测试被测试方法是否按照预期抛出异常
但是需要注意的是我们必须使用一个函数将被测试的函数做一个包装正如下面 getIntArrayWrapFn 所做的那样否则会因为函数抛出错误导致该断言失败。./test/getIntArray.test.js import { getIntArray } from ../src/utils/getIntArray;test(getIntArray(3.3)应该抛出错误, () {function getIntArrayWrapFn() {getIntArray(3.3);}expect(getIntArrayWrapFn).toThrow(getIntArray只接受整数类型的参数);}) .toMatch 传入一个正则表达式它允许我们来进行字符串类型的正则匹配
./test/userInfo.test.js import { getUserInfo } from ../src/utils/userInfo.js;test(getUserInfo().name 应该包含mo, () {expect(getUserInfo().name).toMatch(/mo/i);})
测试异步函数
./servers/fetchUser.js /*** 获取用户信息*/export const fetchUser () {return new Promise((resole) {setTimeout(() {resole({name: moji,age: 24,})}, 2000)})}
./test/fetchUser.test.js import { fetchUser } from ../src/fetchUser;test(fetchUser() 可以请求到一个用户名字为 moji, async () {const data await fetchUser();expect(data.name).toBe(moji)})
这里你可能看到这样一条报错 这是因为 babel/preset-env 不支持 async await 导致的这时候就需要对 babel 配置进行增强可以安装 babel/plugin-transform-runtime 这个插件解决
npm install --save-dev babel/plugin-transform-runtime同时改写 .babelrc {presets: [babel/preset-env, babel/preset-typescript],plugins: [babel/plugin-transform-runtime]}
再次运行就不会出现报错了 .toContain 匹配对象中是否包含
./test/toContain.test.js const names [liam, jim, bart];test(匹配对象是否包含, () {expect(names).toContain(jim);})
检查一些特殊的值nullundefined 和 boolean toBeNull 仅匹配 nulltoBeUndefined 仅匹配 undefinedtoBeDefined 与…相反 toBeUndefinedtoBeTruthy 匹配 if 语句视为 true 的任何内容toBeFalsy 匹配 if 语句视为 false 的任何内容检查数字类型numbertoBeGreaterThan 大于toBeGreaterThanOrEqual 至少大于等于toBeLessThan 小于toBeLessThanOrEqual 最多小于等于toBeCloseTo 用来匹配浮点数带小数点的相等 总结
以上就是文章全部内容相信你阅读完这篇文章后已经掌握了前端单元测试的基本知识甚至可以按照文章教学步骤现在就可以在你的项目中接入单元测试。同时在阅读过程中如果你有任何问题或者有更好见解更好的框架推荐欢迎你在评论区留言
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走
这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
