视觉测试简介

用户界面是主观的。对于“这个看起来对吗？”这个问题的答案取决于你的浏览器、设备和个人喜好。你仍然需要查看渲染出的UI来验证其外观。

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

团队如何防止视觉bug？微软、BBC和Shopify等公司使用什么技术将UI交付给数百万人？我和合著者Tom研究了顶尖团队，以找出真正有效的方法。

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

单元测试没有眼睛

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

单元测试隔离一个模块，然后验证其行为。它提供输入（props、state等）并将输出与预期结果进行比较。单元测试之所以受欢迎，是因为隔离测试模块更容易覆盖边缘情况并准确定位故障来源。

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

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

快照测试呢？

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

实践中，DOM快照很笨拙，因为通过评估HTML块很难确定UI是如何渲染的。

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

视觉测试专为UI而生

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

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

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

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

这听起来工作量很大...

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

了解工具

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