UI 测试入门
UI 测试很棘手。用户期望频繁发布并包含大量功能。但是每个新功能都会引入更多的 UI 和新的状态需要您进行测试。每个测试工具都承诺“简单、不飘忽、快速”，但在细则中有取舍。
领先的前端团队是如何跟上的？他们的测试策略是什么？他们使用什么方法？我研究了 Storybook 社区的十个团队，了解哪些方法有效——Twilio、Adobe、Peloton、Shopify 等。
本指南重点介绍了规模化工程团队使用的 UI 测试技术。您将了解如何实施一种实用的测试策略，该策略平衡了覆盖率、设置和维护。在此过程中，我将指出需要避免的陷阱。
需要测试什么？
所有主流的 JavaScript 框架都采用 组件驱动。这意味着 UI 是从“自底向上”构建的，从原子组件开始，然后逐渐组合成页面。
请记住，每个 UI 元素现在都是一个组件。是的，包括页面。页面和按钮之间的唯一区别在于它们如何消耗数据。
因此，UI 测试现在等同于组件测试。
对于组件而言，不同测试方法（单元、集成、端到端）之间的区别可能很模糊。相反，让我们专注于 UI 的不同可测试特性。
视觉
视觉测试可验证给定的一组 props 和状态，组件是否正确渲染。它们通过为每个组件截取屏幕截图并进行提交到提交的比较来工作，以识别更改。
组合
组件是相互关联的，数据在它们之间流动。您可以对更高级别的组件和页面运行视觉测试来验证这种集成。
交互
交互测试可验证事件是否按预期处理。它们首先在隔离环境中渲染组件。然后模拟用户行为，例如单击或输入。最后，验证状态是否已正确更新。
可访问性
可访问性测试可发现与视觉、听觉、运动能力和其他残疾相关的可用性问题。使用 Axe 等自动化工具作为第一道 QA 来捕获明显的无障碍违规。然后，在真实设备上进行手动 QA，以解决需要人工关注的棘手问题。
用户流程
即使是最基本的操作也需要用户完成一系列跨多个组件的步骤。这是另一个潜在的故障点。Cypress 和 Playwright 等工具允许您针对完整应用程序运行测试以验证此类交互。
理解工作流程
我们已经涵盖了 UI 需要测试的各个方面，但了解如何将它们组合成一个富有成效的工作流程很棘手。如果处理不当，UI 开发过程将感觉像是一个苦差事。只要有细微的实现调整，您的测试就会中断。您必须为每个工具重复测试用例，所有这些都会导致维护噩梦。
我采访的团队尽管规模和技术栈不同，但都有相似的策略。我已将这些经验提炼成这个实用的工作流程
- 📚 使用 Storybook **隔离组件**。编写测试用例，其中使用 props 和模拟数据重现每种状态。
- ✅ 使用 Chromatic **捕获视觉错误并验证组合**。
- 🐙 使用 Vitest 和 Testing Library **验证交互**。
- ♿️ 使用 Axe **审核组件的可访问性**。
- 🔄 使用 Cypress **编写端到端测试，验证用户流程**。
- 🚥 使用 GitHub Actions **自动运行测试，捕获回归**。
开始测试
在接下来的章节中，我们将深入探讨测试堆栈的每一层，并深入研究实现此测试策略的机制。但首先，我们需要一些东西来测试。我将使用 Taskbox 应用程序作为示例。它是一个类似于 Asana 的任务管理应用程序。
请注意，实现细节并不重要，因为我们更关注如何测试此 UI。我们在这里使用 React，但请放心；这些测试概念扩展到所有基于组件的框架。
要获取代码，请运行以下命令
# Clone the template
npx degit chromaui/ui-testing-handbook-react-template ui-testing-guide-code
cd ui-testing-guide-code
# Install dependencies
yarn
初始化一个新的 GitHub 存储库 并将其与本地项目同步。
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/<your username>/ui-testing-guide-code.git
git push -u origin main