持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第14天，点击查看活动详情
问：为什么要测试？
答：增强代码自信！！！
问：面对一个庞大的前端项目，要做自动化测试，应该从何处入手？
答：优先做投资回报率高（最能增强代码自信）的事
问：说人话？
答：见下文！
👇👇👇
前置知识奖杯模型
- 使用静态检查工具来捕获基本错误，例如拼写错误和语法
- 针对应用程序的关键行为和功能编写有效的单元测试
- 开发集成测试以全面审核应用程序，并确保各模块正常地协同工作
- 为关键的
user journey创建端到端 (e2e) 测试用例，确保一切正常
👇👇👇
第一步：配置静态检查工具
- 代码检查：
ESLint - 代码格式化：
Prettier - 类型检查：
TypeScript
第二步：编写一个E2E测试用例
-
首先从用户角度想：如果应用崩了，对哪些功能影响最大？ 然后按照答案列出这些功能的优先级
-
尽可能在一个
E2E测试用例中按照优先级，覆盖最基本/重要的功能，并在生产环境运行测试用例 -
用例都通过之后说明整个应用能正常工作，这将在很大程度上增强我们的代码自信！
第三步：编写一个UT测试用例
- 挑最简单的纯函数捏，在这个过程中安装必要的工具和依赖
第四步：开始写大量的集成测试
- 在前面两步所搭建环境的基础上，尽可能多写集成测试来覆盖 E2E 和单元测试测不到的地方
典型测试误区
× 测试代码的实现方式而不是功能，关注被测代码而不是测试用例 ×
√ 尽可能少地考虑待测代码本身是如何实现的，更多地去思考如何编写测试用例来检查代码的功能 √
-
代码的内部实现，比如：
- 生命周期函数
- 元素的事件处理函数
- 内部组件的状态
-
代码的功能，比如：
- 用户交互：用户是否能够与组件呈现的元素进行交互?
props的改变：当使用新的props值渲染组件时，会发生什么？- 上下文变化：当开发人员做了使组件重新渲染的改动时，会发生什么？
- 订阅变化：当组件发射时间时，会发生什么？（比如改变
vuex，发送请求）
× 盲目地追求100%代码覆盖率 ×
√ 关注更有用的用例覆盖率 √
- 何为测试覆盖率：代码在测试期间运行了哪些行
- 何为用例覆盖率：被测代码支持哪些用例，我们的测试又覆盖了其中的哪些
参考资料：
