目录
- @[TOC](目录)
- 前言
- 自动化测试 VS 手动测试
- 测试分类
- 何为单元测试
- 单元测试的优缺点
- 优点
- 缺点
- 测试案例
- 测试代码
- 测试函数的封装
- 实现 `expect` 方法
- 实现 `test` 函数
- 结语
目录
- @[TOC](目录)
- 前言
- 自动化测试 VS 手动测试
- 测试分类
- 何为单元测试
- 单元测试的优缺点
- 优点
- 缺点
- 测试案例
- 测试代码
- 测试函数的封装
- 实现 `expect` 方法
- 实现 `test` 函数
- 结语
正文开始
,如果觉得文章对您有帮助,请帮我三连+订阅,谢谢
💖💖💖
前言
在日常开发中,我们常会遇到下面的问题:
- 每次在版本发布上线之前,需要在电脑前蹲上好几个小时甚至更长时间对你的应用进行测试,这个过程非常枯燥而痛苦。
- 当代码的复杂度达到一定级别,且维护者的数量不止你一个时,你会逐渐察觉到在开发新功能或修复 bug 时会变得越发小心翼翼。即使代码看起来没问题,你心里还是会犯嘀咕:这个 Feature 会不会带来其他 Bug?这个 Fix 会不会引入其他 “Feature”?
- 当你想要对项目中的代码进行重构时,会花费大量时间进行回归测试。
以上这些问题大多源于开发者使用的最基本的手动测试方式。解决这些问题的根本在于引入自动化测试方案。
自动化测试 VS 手动测试
特性 | 自动化测试 | 手动测试 |
---|---|---|
速度 | 快速,可以连续运行多个测试用例。 | 慢,需要逐个测试用例手动执行。 |
一致性 | 高,每次执行结果一致。 | 低,可能因人为因素导致结果不一致。 |
覆盖率 | 高,可以覆盖大量测试用例。 | 低,可能遗漏一些测试用例。 |
成本 | 初始成本高,需要编写和维护测试脚本。 | 初始成本低,但随着测试用例增加,成本可能增加。 |
维护 | 需要维护测试脚本,但一旦建立,维护成本较低。 | 每次更改需求或功能时,需要重新执行所有测试用例。 |
灵活性 | 低,测试用例需要预先定义。 | 高,可以根据需要随时调整测试用例。 |
准确性 | 高,可以精确执行测试用例。 | 低,可能因人为因素导致测试结果不准确。 |
重复性 | 高,可以重复执行测试用例。 | 低,重复执行测试用例可能会出错。 |
资源 | 需要专门的测试工具和环境。 | 需要测试人员和测试设备。 |
发现问题 | 可以发现一些手动测试难以发现的问题。 | 可以发现一些自动化测试难以发现的问题。 |
适用场景 | 适用于回归测试、持续集成等场景。 | 适用于探索性测试、用户验收测试等场景。 |
可扩展性 | 随着测试用例的增加,可以扩展测试范围。 | 随着测试用例的增加,执行时间可能显著增加。 |
风险 | 测试脚本可能存在缺陷,导致测试结果不准确。 | 测试人员可能因疲劳或疏忽导致测试结果不准确。 |
测试分类
前端开发最常见的测试主要是以下几种:
- 单元测试:验证独立的单元是否正常工作。
- 集成测试:验证多个单元协同工作。
- 端到端测试:从用户角度以机器的方式在真实浏览器环境验证应用交互。
- 快照测试:验证程序的 UI 变化。
何为单元测试
- 单元测试是对应用程序最小的部分(单元)运行测试的过程。通常,测试的单元是函数,但在前端应用中,组件也是被测单元。
- 单元测试可以单独调用源代码中的函数并断言其行为是否正确。
- 与端到端测试不同,单元测试运行速度很快,只需几秒钟即可完成,因此你可以在每次代码变更后运行单元测试,从而快速得到变更是否破坏现有功能的反馈。
- 单元测试应该避免依赖性问题,比如不存取数据库、不访问网络等,而是使用工具虚拟出运行环境。这样可以最小化测试成本,不需花大力气搭建各种测试环境。
单元测试的优缺点
优点
- 提升代码质量,减少 Bug。
- 快速反馈,减少调试时间。
- 让代码维护更容易。
- 有助于代码的模块化设计。
- 代码覆盖率高。
缺点
- 由于单元测试是独立的,无法保证多个单元一起运行时是否正确。
测试案例
上面提到单元测试的单元是函数,我们可以写两个函数,然后进行测试。看下面的例子:
// math.js
function sum (a, b) {return a + b;
}function subtract (x, y) {return x - y;
}module.exports = {sum,subtract
};
测试代码
通过测试代码可以很方便地帮助验证代码的正确性。
const { sum, subtract } = require('./math');const result = sum(1, 2);
const expected = 3;if (result !== expected) {throw new Error(`1 + 2 应该等于 ${expected},但是结果却是 ${result}`);
}const result2 = subtract(2, 1);
const expected2 = 1;if (result2 !== expected2) {throw new Error(`2 - 1 应该等于 ${expected2},但是结果却是 ${result2}`);
}
测试函数的封装
之前示例的测试代码太过繁琐,可以思考如何封装得更简便一些,例如:
expect(sum(1, 2)).toBe(3);
expect(subtract(2, 1)).toBe(1);
这样的测试代码就像自然语言说话一样,很舒服。
实现 expect
方法
function expect (result) {return {toBe (actual) {if (result !== actual) {throw new Error(`预期值和实际值不相等,预期 ${result},实际 ${actual}`);}}};
}
实现 test
函数
增加错误提示信息:
const { sum, subtract } = require('./math');test('测试加法', () => {expect(sum(1, 2)).toBe(3);
});test('测试减法', () => {expect(subtract(2, 1)).toBe(1);
});function test (description, callback) {try {callback();console.log(`${description} 通过测试`);} catch (err) {console.error(`${description} 没有通过测试:${err}`);}
}function expect (result) {return {toBe (actual) {if (result !== actual) {throw new Error(`预期值和实际值不相等,预期 ${result},实际 ${actual}`);}}};
}
结语
自动化测试是前端开发中提升效率、保证质量的利器。它不仅能够减轻手动测试的繁重工作,还能在代码发生变动时迅速提供反馈,确保代码的稳定性和可靠性。通过本文的介绍,相信你已经对自动化测试有了简单理解,后面我会继续介绍更多使用的测试工具
在实际项目中,合理地引入自动化测试,不仅能够大幅度提升开发效率,还能让你在面对复杂的项目需求和频繁的代码变更时更加从容。