视觉测试简介

用户界面是主观的。“这看起来对吗？”这个问题的答案取决于您的浏览器、设备和个人品味。您仍然必须查看渲染的 UI 以验证其外观。

但是，每次提交都手动检查整个 UI 需要很长时间。单元测试和快照测试等不同的方法试图自动化视觉验证。但它们经常以失败告终，因为机器无法从 HTML 标签和 CSS 类的序列中确定 UI 的正确性。

团队如何防止视觉错误？微软、BBC 和 Shopify 使用什么技术向数百万人交付 UI？我的合著者 Tom 和我研究了领先的团队，以找出实际有效的方法。

本手册介绍了视觉测试，这是一种务实的方法，它结合了人眼的准确性和机器的效率。视觉测试不是将人从测试等式中移除，而是使用工具将他们的精力集中在需要注意的特定 UI 更改上。

单元测试没有眼球

要掌握视觉测试，从单元测试开始是有意义的。现代 UI 是组件驱动的——它们由模块化部件组成。组件构造允许您将 UI 渲染为 props 和状态的函数。这意味着您可以像对待任何其他函数一样对组件进行单元测试。

单元测试隔离一个模块，然后验证其行为。它提供输入（props、状态等），并将输出与预期结果进行比较。单元测试是可取的，因为隔离测试模块可以更轻松地覆盖边缘情况并查明故障来源。

核心问题是，UI 的大部分内在复杂性是视觉的——生成的 HTML 和 CSS 在用户屏幕上的渲染的具体细节。

单元测试非常适合评估具体输出：2 + 2 === 4。但它们不太适合 UI，因为很难辨别 HTML 或 CSS 的哪些细节会影响外观以及如何影响。例如，HTML 更改并不总是影响 UI 的外观和感觉。

快照测试呢？

快照测试提供了一种验证 UI 外观的替代方法。它们渲染组件，然后将生成的 DOM 捕获为“基线”。后续更改会将新的 DOM 与基线进行比较。如果存在差异，开发人员必须显式更新基线。

在实践中，DOM 快照很笨拙，因为通过评估 HTML blob 来确定 UI 的渲染方式非常棘手。

快照测试与其他自动化 UI 测试一样，都存在脆弱性。无论组件的渲染输出是否发生更改，组件内部工作的任何更改都需要更新测试。

视觉测试专为 UI 设计

视觉测试旨在捕获 UI 外观的变化。您可以使用像 Storybook 这样的组件浏览器来隔离 UI 组件、模拟其变体，并将支持的测试用例保存为“故事”。

在开发期间，通过在浏览器中渲染组件来“运行”快速手动验证，以查看其外观。通过切换组件浏览器中列出的每个测试用例来确认组件的变体。

在 QA 中，使用自动化来检测回归并强制执行 UI 一致性。像 Chromatic 这样的工具在一致的浏览器环境中捕获每个测试用例的图像快照，包括标记、样式和其他资源。

每次提交，新的图像快照都会自动与先前接受的基线快照进行比较。当机器检测到视觉差异时，开发人员会收到通知，以批准有意更改或修复意外错误。

这听起来像很多工作...

这听起来可能很费力，但最终比筛选来自自动化测试的误报、更新测试用例以匹配细微的 UI 更改以及加班使测试再次通过更容易。

学习工具

现在我们对视觉测试有了一定的了解，让我们来看看启用它所需的主要工具：组件浏览器。在下一章中，我们将了解组件浏览器如何帮助开发人员构建和测试组件。