视觉测试简介

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

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

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

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

单元测试没有“眼睛”

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

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

核心问题在于，UI 的固有复杂性很大程度上是视觉上的——HTML 和 CSS 在用户屏幕上的渲染细节。

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

快照测试怎么样？

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

实际上，DOM 快照很麻烦，因为通过评估 HTML 块来确定 UI 的渲染方式很困难。

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

视觉测试是为 UI 而设计的

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

在开发过程中，通过在浏览器中渲染组件来进行快速的手动验证，看看它的外观。通过切换组件浏览器中列出的每个测试用例来确认组件的变体。

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

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

这听起来像是很多工作……

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

学习工具

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