这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天
- 什么是自动化测试?
- 为什么要做自动化测试?
- 前端自动化测试的技术选型
- 如何进行前端自动化测试
- 自动化测试的持续集成
理想的软件开发V模型 需求分析->概要设计->详细设计->编码->单元测试->集成测试->系统测试->验收测试
单元测试：开发人员通过编码的方式对自己的代码进行正确性校验
集成测试：在不同模块集成以后，QA团队对其正常通信和功能进行多维度测试
系统测试：QA团队对整个系统进行端对端测试
为什么要做自动化测试
集成测试和前端自动化测试
集成测试：测试人员保障整体系统功能符合预期的一种方式
研发角度的自动化测试：虽然也是开发保障系统功能的一种方式，但是时间点不太一样；关注更多的是后续功能的维稳，而不完全本次功能的稳定
前端为什么要做自动化测试
- 统一代码风格
- 组件Readme 用例化，保持时效性
- 有效审视代码中的耦合逻辑
- 避免后续迭代影响到历史功能，发布breaking change
前端自动化测试的技术选型
The more your tests resemble the way your software is used, the more confidence they can give you.
---《Google软件测试之道》
技术选型：开发成本低；不会频繁变更；上手快，学习成本低
Role：无障碍模型。W3C规定每一个元素都有一个对应的role，就是角色；例如一个原生的button标签，它就有一个button的role。
技术选型
- Jest + React testing library + Cypress + storybook :
- 测试框架: Jest(提供一个可运行的环境、测试结构、结果报告、代码覆盖、断言、mocking、snapshot )
- 测试辅助库: react-testing-library (dom查询， 断言和事件的模拟，React18 推荐的UI自动化的集大成测试辅助库)
- Cypress + storybook: E2E端对端测试，覆盖单元测试不易于覆盖的复杂场景
配置
配置示例仓库: github.com/czm12904337…
demo仓库: https://github.m/czm1290433700/test.demo
自动化测试的基本元素
- 模块（一类用例）
- 用例，一组需要验证的逻辑
- 渲染元素
- 查询
- 断言，对查询元素的预期
查询
Get:返回查询的匹配节点，如果没元素匹配，则会报错(针对单查如果查到多个也会报错);
Query:返回查询的匹配节点，如果没有元素匹配会返回null, 但是不会报错(同样针对单查，如果查到多个匹配元素也会报错)
Find:返回一个Promise, 默认超时时间为1000ms，如果没有元素匹配或者查找超时，Promise 状态切为reject(同样 针对单查，如果查到多个元素，也会返回reject )
ARIA(Accessible Rich Internet Applications)是一组属性，用于定义使残障人士更容易访问Web内容和Web 应用程序(尤其是使用JavaScript 开发的应用程序)的方法。
通过无障碍属性查询相比通过类名查询减少对代码结构的依赖，使得用例更为强健，不容易被修改。
断言 可以分为Jest 和Jest Dom提供，是一组判断当前元素是否符合某种预期的效果
Jest提供了一系列基础的断言，类似toBe，not，toEqual等.可以移步jestjs.io/docs/gettin… 查阅
Jest Dom是react testing library 补充的一系列与DOM相关的特殊断言，可以移步github.com/testing-lib… 查阅
事件模拟
针对这种场景，React Testing Library 提供了两种手段来模拟，fireEvent 和 userEvent
我们更推荐使用userEvent, 相比fireEvent，userEvent更贴切真实场景地模拟了事件，而fireEvent 只是调度对应的事件。
我们书写的用例应该尽可能从用户视角来展开，而不是代码层面，这样对于用例本身来说，才是更强健的
