UI 测试简介

UI 测试很麻烦。用户期待频繁发布并包含丰富功能的版本。但每个新功能都会引入更多的 UI 和新状态，而这些您都需要测试。每个测试工具都承诺“简单、稳定、快速”，但在细节之处都有取舍。

领先的前端团队是如何跟上步伐的？他们的测试策略是什么，使用了哪些方法？我研究了 Storybook 社区的十个团队，以了解哪些方法行之有效——包括 Twilio、Adobe、Peloton、Shopify 等等。

本指南重点介绍了成熟工程团队使用的 UI 测试技术。您将学习如何实施一个实用的测试策略，平衡覆盖范围、设置和维护。在此过程中，我将指出需要避免的陷阱。

需要测试什么？

所有主流 JavaScript 框架都是组件驱动的。这意味着 UI 是从“底部向上”构建的，从原子组件开始，逐步组合成页面。

请记住，现在 UI 的每个部分都是一个组件。没错，这包括页面。页面和按钮之间的唯一区别在于它们如何消费数据。

因此，UI 测试现在等同于组件测试。

对于组件来说，不同测试方法——单元、集成、端到端——之间的界限可能很模糊。相反，我们来关注 UI 中可以测试的不同特性。

可视化

可视化测试验证组件在给定一组 props 和状态时是否正确渲染。其工作原理是截取每个组件的屏幕截图，并进行提交到提交的比较以识别变化。

组合

组件是相互连接的，数据在它们之间流动。您可以通过对更高级别的组件和页面运行可视化测试来验证这种集成。

交互

交互测试验证事件是否按预期处理。它们首先在隔离环境中渲染组件。然后模拟用户行为，例如点击或输入。最后，验证状态是否正确更新。

可访问性

可访问性测试发现与视力、听力、行动能力及其他残疾相关的可用性问题。使用 Axe 等自动化工具作为质量保证的第一道防线，以捕获明显的可访问性违规。然后，对需要在真实设备上进行人工质量保证的更棘手问题进行后续检查。

用户流程

即使是最基本的任务，也需要用户跨多个组件完成一系列步骤。这又是另一个潜在的故障点。Cypress 和 Playwright 等工具允许您对整个应用程序运行测试，以验证此类交互。

理解工作流程

我们已经讨论了需要测试的 UI 的不同方面，但知道如何将它们组合成一个高效的工作流程却很棘手。如果做错了，UI 开发过程就会变得非常缓慢。每当实现细节调整时，您的测试就会失败。您必须为每个工具重复编写测试用例，这一切都会演变成维护的噩梦。

我采访的团队尽管规模和技术栈不同，但都有相似的策略。我将这些经验提炼成了这个实用的工作流程

• 📚 使用 Storybook 隔离组件。编写测试用例，使用 props 和模拟数据重现每种状态。
• ✅ 使用 Chromatic 捕获视觉 Bug 并验证组合。
• 🐙 使用 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