@testing-library/react 是 React 官方推荐的 UT 框架。但我认为它不仅仅是 UT 的框架,它可以发展成产品端到端自动化测试的解决方案。
现在流行叫 QA,而不是测试。这是因为大家意识到:保证软件质量,仅仅靠编码完成后的测试是不够的,从需求分析、设计阶段开始就要严格把关。QA 的职责从之前的“编码完成后测试”延伸到软件开发的全过程。
参与了全过程的 QA,不仅对测试工作更有把握,还能提出产品方面的建议、制定有效的项目计划、找出开发设计存在的问题。例如:
- 功能是不是过度设计了?用户只要 xx 就够了。
- 在什么时间点合代码?
- 这样的表结构,功能满配的情况下,数据量是多少?这样规模的数据,用这样的算法操作,是否影响系统性能?
现在流行敏捷开发,为了保证质量和速度,测试的工作需要向自动化发展。因此 QA 又多了一项任务:编写端到端自动化测试脚本。
这种端到端自动化测试脚本,编写、调试体验很差。打开一个浏览器,模拟用户在网页操作,速度很慢,盯着看让人心急。但编写、调试阶段你还不得不盯着看。其实前端开发更了解元素定位,更清楚用什么定位方式更可靠,但因为编写效率低,影响开发进度,这个工作一般都是 QA 来做。
现在前端流行 React 框架。React 把渲染层分离了,使得“页面渲染在内存,而不是浏览器”成为了可能。从而 React UT 可以变得很轻巧。
@testing-library/react
是 React 官方推荐的 UT 框架。但我认为
@testing-library/react
不仅仅是 UT 的框架,它会发展成产品端到端自动化测试的解决方案。因为:
- 测试脚本是在 node 环境中运行的。这样调用其他脚本,如环境初始化等脚本非常方便。
-
测试脚本的编写的内容也是模拟用户操作。
如下方代码示例,模拟初始化加载和用户点击刷新。
test("loading&refreshing", async () => {
render(<App />);
expect(
await screen.findByText(/apolis/i)
).toBeInTheDocument();
user.click(
screen.getByRole("button", {
name: /refresh/i,
})
);
expect(
await screen.findByText(/kzhang/i)
).toBeInTheDocument();
});
我理想的样子是:QA 和前端开发共同实现产品的端到端自动化测试。QA 设计测试用例、搭建测试环境、提供用于测试环境初始化的脚本;前端按照 QA 设计的测试用例编写自动化测试脚本,自动化测试脚本中会调用 QA 的环境初始化脚本。