# 质量保证体系
通过各类型自动化工具及测试用例对代码质量进行检测
# 团队应用现状
- 语法检查工具
- 单元测试
- 端对端测试
目前所有自动化检查的方式仅为手动运行检测,后续将视情况切换为强制执行方式,检测不通过则不允许编译与发行
# 语法检查
语法检查工具用于检查代码的语法是否正确、风格是否符合要求
JavaScript 是一个动态的弱类型语言,在开发中比较容易出错。因为没有编译程序,为了寻找 JavaScript 代码错误通常需要在执行过程中不断调试。像 ESLint 这样的可以让程序员在编码的过程中发现问题而不是在执行的过程中。
# 使用工具
目前使用规则为宽松模式,后续将逐步增加规则要求级别
# 运行方式
npm run lint
# 检查结果要求
ESlint 命令行输出
DONE No lint errors found!
代表了语法检查通过
# 单元测试
单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作,可以理解为 白盒测试 的行为。
# 为什么要写单元测试?
Web应用程序越来越复杂,这意味着有更多的可能出错。测试是帮助我们提高代码质量、降低错误的最好方法和工具之一
- 测试可以确保得到预期结果
- 加快开发速度
- 方便维护
- 提供用法的文档
通过测试提供软件的质量,在开始的时候,可能会降低开发速度。但是从长期看,尤其是那种代码需要长期维护、不断开发的情况,测试会大大加快开发速度,减轻维护难度
# 使用功能库
功能库 | 作用 |
---|---|
Mocha (opens new window) | 单元测试引擎 |
Chai (opens new window) | 断言库 |
JsDom (opens new window) | 虚拟浏览器容器 |
@vue/test-utils (opens new window) | vue 官方提供单元测试工具集 |
# 运行方式
npm run test:unit
# 适用范围
很多时候,一些简单的功能场景,例如表单增、删、改、查等并没有编写单元测试的必要,况且编写单元测试需要不少时间成本,建议编写单元测试的场景如下
- 系统底层 API
- 功能封装类
- 功能组件
- 关联计算
- 业务集成联动
对于功能封装函数,更是应该增加多种测试用例进行功能覆盖,对于边界测试更是其中重中之重
# 端对端测试(End-to-end)
端对端测试,简单地可以理解为站在用户角度的测试。站在用户的角度,他不需要知道软件的内部实现是怎么样的,只是使用即可;那么端对端测试模拟的就是用户的行为,只负责打开软件/浏览器,按序执行测试用例,并检查测试结果是否符合预期,它是 黑盒测试 的行为。
# 使用功能库
# 运行方式
npm run test:e2e
← 网页能力开放平台