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