UI 测试导论
UI 测试很麻烦。用户期望频繁发布包含各种功能的版本。但是，每项新功能都会引入更多 UI 和新的状态，而您必须对这些 UI 和状态进行测试。每种测试工具都承诺“简单、不脆弱、快速”，但在细则中都有权衡取舍。
领先的前端团队是如何跟上步伐的？他们的测试策略是什么，他们使用什么方法？我研究了 Storybook 社区的十个团队，以了解哪些方法有效 — Twilio、Adobe、Peloton、Shopify 等。
本指南重点介绍了规模化工程团队使用的 UI 测试技术。您将学习如何实施一种务实的测试策略，该策略可以平衡覆盖率、设置和维护。在此过程中，我将指出需要避免的陷阱。
什么需要测试？
所有主要的 JavaScript 框架都是组件驱动的。这意味着 UI 是从“自下而上”构建的，从原子组件开始，逐步组合成页面。
请记住，每个 UI 片段现在都是一个组件。是的，包括页面。页面和按钮之间的唯一区别在于它们如何使用数据。
因此，测试 UI 现在与测试组件同义。
对于组件而言，各种测试方法（单元测试、集成测试、e2e 测试）之间的区别可能很模糊。相反，让我们关注我们可以测试的 UI 的不同特征。
视觉
视觉测试验证组件在给定一组属性和状态的情况下是否正确渲染。它们的工作原理是拍摄每个组件的屏幕截图，并将它们逐次提交进行比较，以识别更改。
组合
组件是相互连接的，数据在它们之间流动。您可以通过对更高级别的组件和页面运行视觉测试来验证此集成。
交互
交互测试验证事件是否按预期处理。它们首先在隔离状态下渲染组件。然后模拟用户行为，例如单击或输入。最后，验证状态是否已正确更新。
可访问性
可访问性测试揭示与视觉、听力、行动和其他残疾相关的可用性问题。使用 Axe 等自动化工具作为 QA 的第一道防线，以捕获明显的辅助功能违规行为。然后，在真实设备上进行手动 QA，以解决需要人工注意的更棘手的问题。
用户流程
即使是最基本的任务也需要用户完成跨多个组件的一系列步骤。这又是另一个潜在的故障点。Cypress 和 Playwright 等工具允许您针对完整应用程序运行测试，以验证此类交互。
了解工作流程
我们已经介绍了需要测试的 UI 的不同方面，但了解如何将它们组合成高效的工作流程是很棘手的。如果您弄错了，UI 开发过程会感觉像一场苦战。每当实现进行调整时，您的测试就会中断。您必须为每个工具复制测试用例，并且所有这些都会演变成维护噩梦。
我采访的团队尽管规模和技术堆栈存在差异，但都采用了类似的策略。我已将这些经验提炼成这种务实的工作流程
- 📚 使用 Storybook 隔离组件。编写测试用例，在其中使用属性和模拟数据重现每个状态。
- ✅ 使用 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