单元测试
前端中主要用到e2e测试和单元测试
unit测试是程序员写好自己的逻辑后可以很容易的测试自己的逻辑返回的是不是都正确。
e2e代码是测试所有的需求是不是都可以正确的完成,而且最终要的是在代码重构,js改动很多之后,需要对需求进行测试的时候测试代码是不需要改变的,你也不用担心在重构后不能达到客户的需求。目前常用的工具有,selenium, puppeteer,phantom,protractor(angular), Nightwatch(Vue)等等
TDD:测试驱动开发
BDD:行为驱动开发
哪些情况下你可能需要写前端UT? 来做一组判断题(有一个yes就需要写)
- 你写的是个util类,是会被其他类调用的那种?
- 你写的是一个公共component,是会被其他工程调用的那种?
- 你写的是一个开源项目
哪些情况需要写e2e(如果你的答案里有2个以上的yes,可能e2e AT(e2e自动化测试)并不是现阶段必须要引入的)
- 测试团队是否兵强马壮 (基于人海战术的人肉e2e测试)
- 产品UI是否相对不稳定,经常大改 (改e2e case都来不及)
- 测试团队是否已经熟练掌握自动化测试技术,并已经运用起来 (QA来写e2e自动测试,理想国,前端就可以甩手了)
- 每一个迭代周期,留给QA测试时间是否充裕 (人肉e2e测试时间充足)
- Service接口的测试覆盖率是否很高,后端UT的覆盖率是否很高 (底层建筑稳,隐患少)
- 每一个迭代周期,留给前端开发的时间是否很紧张 (前端写完业务代码,也要有时间写e2e代码)
关于前端UT:业务代码可以不写UT
关于前端e2e: 推荐用e2e AT来覆盖前端的业务代码,并纳入开发流程
单元测试的首要目的不是为了能够编写出大覆盖率的全部通过的测试代码,而是需要从使用者(调用者)的角度出发,尝试函数逻辑的各种可能性,进而辅助性增强代码质量。
从不同的角度,可将测试划分为如下不同的种类:
- 从人工操作还是写代码来操作的角度,可以分为手工测试和自动化测试;
- 从是否需要考虑系统的内部设计角度,可以分为白盒测试和黑盒测试;
- 从测试对象的级别,可以分为单元测试、集成测试和端到端测试;
- 从测试验证的系统特性,又可以分为功能测试、性能测试和压力测试。
umi
roadhog已经通过umi-test集成了jest的测试环境,一般项目所说的配置你都不需要做了。.babelrc文件也不需要了,配置只会导致测试脚本运行出错。
直接在根目录下新建一个__test__文件,你就可以开始写测试案例了,直接运行npm run test。
注意:如果需要额外配置jest的话,需要使用jest配置项中的setupFiles字段来指定额外的配置;单单在项目的package.json下为jest添加配置是不会生效的。
Enzyme
在使用enzyme时需要适配对应的react版本。所以需要安装 npm install --save-dev enzyme-adapter-react-16
在使用Enzyme的文件里顶部添加 Enzyme.configure({ adapter: new Adapter() })
而为了避免每个测试文件都这么写,可以再test目录下新建一个配置文件:
import Enzyme from 'enzyme'; |
然后测试文件的时候只需要引用这个配置文件即可:
import {assert} from 'chai' |
常用方法:
- get(index):返回指定位置的子组件的DOM节点
- at(index):返回指定位置的子组件
- first():返回第一个子组件
- last():返回最后一个子组件
- type():返回当前组件的类型
- text():返回当前组件的文本内容
- html():返回当前组件的HTML代码形式
- props():返回根组件的所有属性
- prop(key):返回根组件的指定属性
- state([key]):返回根组件的状态
- setState(nextState):设置根组件的状态
- setProps(nextProps):设置根组件的属性