现在流行叫 QA，而不是测试。这是因为大家意识到：保证软件质量，仅仅靠编码完成后的测试是不够的，从需求分析、设计阶段开始就要严格把关。QA 的职责从之前的“编码完成后测试”延伸到软件开发的全过程。
参与了软件开发全过程的 QA，不仅对测试工作更有把握，还能提出产品方面的建议、制定有效的项目计划、找出开发设计存在的问题。例如：
- 功能是不是过度设计了？用户只要 xx 就够了。
- 在什么时间点合代码？
- 这样的表结构，功能满配的情况下，数据量是多少？这样规模的数据，用这样的算法操作，是否影响系统性能？
现在流行敏捷开发，为了保证质量和速度，测试的工作需要向自动化发展。因此 QA 又多了一项任务：编写端到端自动化测试脚本。
这种端到端自动化测试脚本，编写、调试体验很差。打开一个浏览器，模拟用户在网页操作，速度很慢，盯着看让人心急。但编写、调试阶段你还不得不盯着看。其实前端开发更了解元素定位，更清楚用什么定位方式更可靠，但因为编写效率低，影响开发进度，这个工作一般都是 QA 来做。
jsdom 实现了浏览器 api，运行在 nodejs 环境中，可以模拟浏览器。基于 React 的 web 项目 UT 时，ReactDOM 把组件渲染到 jsdom 模拟的浏览器中。
这个方案只用来做 UT 可惜了。如果你把 jsdom 就看作真实浏览器，把请求变成真实请求，这不就是“端到端测试”吗？和 selenium 的区别仅仅是：一个用 jsdom 浏览器，一个用真实浏览器。就连基于 @testing-library/react 的测试脚本，写的也是模拟用户操作，和 selenium 脚本差不多。如下方代码示例，模拟初始化加载和用户点击刷新：
it("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 的环境初始化脚本。
在实际工作中，“端到端测试”也许是终极目标，要实现这一目标，把 UT 做起来是第一步。
一些想法：
- 使用 msw 做 UT 和编码的
Mock Server，共用handlers。开发新功能时，UT 和编码一起进行，练习看着 test result 开发，通过这种方式，让团队熟悉@testing-library。 - 团队积累 UT 经验的同时，需总结、提取、封装适合项目 UT 的工具库。
- 提高 UT Case 的质量，设计更容易发现错误的 UT Case。这一方面需要学习一些测试理论，一方面需要多总结项目中的衰退 Bug。
让 UT 从无到有到快到好。
